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provided on an annual subscription basis to the Entity holding the subscription (“YOU”), pursuant to 
your Terms of Usage Agreement with ODVA, Inc. (ODVA) for the technology contained in the Final 
Specification. 
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continuing rights to the single user subscription as allowed under your Terms of Usage Agreement. 
This single user subscription permits access to the electronic files for the volumes contained on the 
distribution CD by your employees and on-site contracted individuals performing typical employee 
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Revisions 


This edition of the CIP Networks Library Volume 2: EtherNet/IP Adaptation of CIP contains 
the following changes from the previous Edition. Please see the change bars on the pages noted 
here for specific modifications. Note: Some of the pages within the ranges noted may not 
contain any changes. 


Chapt-Sect | Pages Description 
IP Address Encoding 
3.3.7 3-9, 10 e Add dotted decimal to bullets and add new 2™ paragraph and add reference to Volume 1, 
aaa j Appendix C in last paragraph 
1Gb Ethernet Link Object 
5-5.2 5-25 e Add revision 4 
5-5.3.1 5.25 e Change attribute 1 to required and value to 4 
¢ Remove footnote | 
5-5.3.2 5-29, 30 e Add attributes 12, 13, changes to footnotes add footnote 4 
5-5.3.2.2 5-31 e Change definition of bit 5 to refer to attribute 11 definition 
anh 5-32 ¢ Changes to forced duplex mode definition 
on 5-32-33 e Add second paragraph, delete last sentence of first paragraph, changes in last paragraph 
5-5.3.2.11 5-34 ¢ Add new section for Attribute 11 
5-5.3.2.12 5-34, 35 ¢ Add new section for Attribute 12 & 13 
5-5.4.2 5-35, 36 e Change table and minor changes in paragraphs 
5-5.5 5-37 ¢ Changes to table 
5-5.5.1 5-37 ¢ Add new counters 
G-3.1 G-9 ¢ Add attributes 12 and 13 to table G-3.1 
EtherNet/P Indicator Visibility 
9-4.2.2 9-6 ¢ Changes to visibility of indicators requirements 
Typos and misc corrections 
6 7 e Changes throughout chapter to update chapter/volume references to current style 
guidelines and to update references to Vol 1 Chapter 5 to SA/SB as appropriate 
7 = e Changes throughout chapter to update chapter/volume references to current style 
guidelines 
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Preface 
Organization of the CIP Networks Specifications 


Today, four networks - DeviceNet™ , ControlNet™ , EtherNet/IP™ and CompoNet™ - use the 
Common Industrial Protocol (CIP) for the upper layers of their network protocol. For this 
reason, ODVA manages and distributes the specifications for CIP Networks in a common 
structure to help ensure consistency and accuracy in the management of these specifications. 


The following diagram illustrates the organization of the library of CIP Network specifications. 
In addition to CIP Networks, CIP Safety™ consists of the extensions to CIP for functional 
safety. 
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This common structure presents CIP in one volume with a separate volume for each network 
adaptation of CIP. The specifications for the CIP Networks are two-volume sets, paired as 
shown below. 


The EtherNet/IP specification consists of: 
Volume 1: Common Industrial Protocol (CIP ™ ) 
Volume 2: EtherNet/IP Adaptation of CIP 

The DeviceNet specification consists of: 
Volume 1: Common Industrial Protocol (CIP ™ ) 
Volume 3: DeviceNet Adaptation of CIP 

The ControlNet specification consists of: 
Volume 1: Common Industrial Protocol (CIP ™ ) 
Volume 4: ControlNet Adaptation of CIP 


The CompoNet specification consists of: 


Volume 1: Common Industrial Protocol (CIP ™) 
Volume 6: CompoNet Adaptation of CIP 

The specifications for CIP Safety™ is distributed in a single volume: 
Volume 5: CIP Safety 


The specification for integrating Modbus Devices is distributed in a single volume: 
Volume 7: Integration of Modbus Devices into the CIP Architecture 


Specification Enhancement Process 


The specifications for CIP Networks are continually being enhanced to meet the increasing 
needs of users for features and functionality. ODVA has implemented a Specification 
Enhancement Process in order to ensure open and stable specifications for all CIP Networks. 
This process is ongoing throughout the year for each CIP Network Specification as shown in 
the figure below. New editions of each CIP Network specification are published on a periodic 
basis. 


_ Members Develop Specification 


New Specification Enhancements in Special Interest 
dition Published Groups (SIGs) 


Conformance Tests 
Tindated . 
Technical Review Board 


Reviews and Approves 
Specification Enhancements 


Member Review and 
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Introduction 


EtherNet/IP (Ethernet/Industrial Protocol) is a communication system suitable for use in 
industrial environments. EtherNet/IP allows industrial devices to exchange time-critical 
application information. These devices include simple I/O devices such as sensors/actuators, as 
well as complex control devices such as robots, programmable logic controllers, welders, and 
process controllers. 


EtherNet/IP uses CIP (Common Industrial Protocol), the common network, transport and 
application layers also shared by ControlNet and DeviceNet. EtherNet/IP then makes use of 
standard Ethernet and TCP/IP technology to transport CIP communications packets. The result 
is a common, open application layer on top of open and highly popular Ethernet and TCP/IP 
protocols. 


EtherNet/IP provides a producer/consumer model for the exchange of time-critical control data. 
The producer/consumer model allows the exchange of application information between a 
sending device (e.g., the producer) and many receiving devices (e.g., the consumers) without 
the need to send the data multiple times to multiple destinations. For EtherNet/IP, this is 
accomplished by making use of the CIP network and transport layers along with IP Multicast 
technology. Many EtherNet/IP devices can receive the same produced piece of application 
information from a single producing device. 


EtherNet/IP makes use of standard IEEE 802.3 technology; there are no non-standard additions 
that attempt to improve determinism. Rather, EtherNet/IP recommends the use of commercial 
switch technology, with 100 Mbps bandwidth and full-duplex operation, to provide for more 
deterministic performance. 


NOTE: EtherNet/IP does not require specific implementation or performance requirements due 
to the broad range of application requirements. However, work is underway to define a 
standard set of EtherNet/IP benchmarks and metrics by which the performance of devices will 
be measured. These measurements may become required entries within a product's Electronic 
Data Sheet. The goal of such benchmarks and metrics will be to help the user determine the 
suitability of a particular EtherNet/IP device for a specific application. 


The figure below illustrates how EtherNet/IP, DeviceNet and ControlNet share the CIP 
Common layers. 
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Figure 1-1.1 CIP Common Overview 
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The EtherNet/IP specification is divided into the following chapters: 


Description 


DeviceNet 
Adaptation & Data Link 
Data Link Layers Layer 
[CAN] 
Physical 
Layer 
1-2 Scope 
Chapter Title 
1 Introduction 
2 Encapsulation 
Protocol 
3 Mapping of Explicit 
and I/O Messaging to 
TCP/IP 
4 Object Model 
5 Object Library 
6 Device Profiles 
7 Electronic Data Sheets 
8 Physical Layer 
9 Indicators and Middle 
Layers 
10 Bridging and Routing 


This chapter of the specification. 


Specifies the encapsulation protocol that is used to transport CIP packets 
over TCP/IP networks. The encapsulation protocol specified in this chapter 
may also be used to encapsulate non-CIP protocols. 


Contains EtherNet/IP-specific additions to the CIP Network and Transport 
layers. Specifies how the encapsulation protocol defined in Chapter 2 is 
used to transport CIP Network and Transport layer packets over TCP/IP 
networks. 


Contains EtherNet/IP-specific additions to the CIP object model. 
Supplements the CIP object library with objects specific to EtherNet/IP. 
Contains EtherNet/IP-specific additions to the CIP device profile library. 
Specifies additions to the CIP EDS definition required for EtherNet/IP. 
Specifies media and physical layer requirements for industrial use. 


Specifies TCP/IP requirements of EtherNet/IP devices. This chapter also 
specifies the standard appearance and behavior of EtherNet/IP diagnostic 
LEDs. 


Additions to the CIP routing definition. 
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This chapter is the Introduction to EtherNet/IP. The following drawing shows the relationship 
of these chapters to each other and to the CIP Common specification (published separately by 
ODVA). Both this specification (volume2) and the CIP Common specification (volume1) are 
required to completely specify an EtherNet/IP product. The encapsulation protocol defined in 
Chapter 2 of this specification is also suitable to encapsulate other industrial protocols, as 
illustrated in the following drawing. However, the specific details of encapsulating other 
protocols are not included in this release of the specification. 


As can be seen in Figure 1-2.1, the encapsulation protocol in chapter 2 uses a TCP/IP layer to 
insulate it from the network medium. As such, the encapsulation protocol may be used on any 
medium that supports TCP/IP. For example, the encapsulation protocol could run on an FDDI 
or PPP network. Chapter 9 (Indicators and Middle Layers) requires conformance with the RFC 
that documents how TCP/IP is implemented on a particular network. Furthermore, chapter 8 
(Physical Layers) narrows the scope of certified EtherNet/IP implementations to run on either 
10 or 100 Mb Ethernet. Specifically, chapter documents two permissible conformance levels 
of devices: one called “commercial” and the other “industrial”. Other conformance levels may 
be added through modification to this specification. 


Figure 1-2.1 shows the relationship between the various parts of the EtherNet/IP specification. 
As shown in the figure, the darker sections (chapters 2-7 and 10) are predominately 
documented by the CIP Common specification (volume 1). The corresponding chapters of the 
EtherNet/IP Adaptation of CIP (volume 2) supplements or modifies these chapters of the CIP 
Common specification in some areas. The lightly shaded sections (chapters 2, 3, 8 and 9) are 
predominately documented by volume 2. These chapters contain information applicable 
specifically to EtherNet/IP devices, but not necessarily to those on other CIP networks (for 
example, DeviceNet or ControlNet). 


Figure 1-2.1 Document Organization Overview 
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1-3 


1-3.1 


References 


Normative References 

ISO 7498-1:1984, Information processing systems — Open systems interconnection — Basic 
reference model 

ISO 7498/AD1: 1987, Information processing systems — Open systems interconnection — 
Connectionless data transmission 

ISO 7498-3:1987, Information processing systems — Open systems interconnection — Naming 
and addressing 

ISO/IEC 8886:1992, Information technology — Open systems interconnection — 
Telecommunications and information exchange between systems — Data link service definition 
ISO/IEC 10039:1990, Information technology — Telecommunication and information 
exchange between systems — Medium access control service definition 

ISO/TR 8509:1987, Information processing systems — Open systems interconnection — 
Service conventions 

ISOAHEC 10731:1992, Information technology — Open systems interconnection — Conventions 
for the definition of OSI services 

ISO 8802-2:1989, Information processing systems — Local area networks — Part 2: Logical 
link control 

ISO/IEC 8802-3:1993, Information technology — Local and metropolitan area networks — 
Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and 
physical layer specifications 

ISO/IEC 8802-4:1990, Information processing systems — Local area networks — Part 4: 
Token - passing bus access method and physical layer specifications 

ANSI X3.159-1989, American National Standard for Information Systems — Programming 
Language C 

IEEE Std 802.1D — 2004, Media Access Control (MAC) Bridges - IEEE Standard for Local and 
Metropolitan Area Networks 

IEC 61076-2-109 — Circular connectors — Detail specification for connectors M 12 x 1 with 
screw-locking, for data transmissions with frequencies up to 500 MHz. 

ISOAEC 11801 — Information technology —Generic cabling for customer premises 

TIA 568-C series Standards — Commercial Building Telecommunications Cabling Standard 
IEC 62439-3 (2012-07) Ed. 2.0, Industrial communication networks — High availability 
automation networks — Part 3: Parallel Redundancy Protocol (PRP) and High-availability 
Seamless Redundancy (HSR) 
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1-4 Additional Reference Material 


Strategies for Real-time Systems Specification” by D. J. Hatley and I. A. Pirbhai 


CEN/CENELEC Internal Regulations Part 3: Rules for the drafting and presentation of 
European Standards (PNE-Rules) - 1991-09 


RFC 768: August 1980, User Datagram Protocol 

RFC 791: September 1981, Internet Protocol 

RFC 792: September 1981, Internet Control Message Protocol 

RFC 793: September 1981, Transmission Control Protocol 

RFC 826: November 1982, An Ethernet Address Resolution Protocol 


RFC 894: April 1984, A Standard for the Transmission of IP Datagrams over Ethernet 
Networks 


RFC 1035:1987, Domain names - implementation and specification 


RFC 1103: June 1989, A Proposed Standard for the Transmission of IP Datagrams over FDDI 
Networks 


RFC 1112: August 1989, Host Extensions for IP Multicasting 

RFC 1117:1989, Internet numbers 

RFC 1122: October 1989, Requirements for Internet Hosts -- Communication Layers 
RFC 1123: October 1989, Requirements for Internet Hosts -- Application and Support 
RFC 1127: October 1989, A Perspective on the Host Requirements RFCs 


RFC 1171: July 1990, The Point-to-Point Protocol for the Transmission of Multi-Protocol 
Datagrams Over Point-to-Point Links 


RFC 1201; February 1991, Transmitting IP Traffic over ARCNET Networks 
RFC 1392: January 1993, Internet Users' Glossary 
RFC2236: November 1997, Internet Group Management Protocol, Version 2 
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1-5 Definitions 


For the purposes of this standard, the following definitions apply. Also see CIP Common 
Specification, Chapter 1 for additional definitions. 


Term 


Definition 


automation outlet 


The interface where the generic telecommunications cabling ends and the automation 
specific cabling begins, including the interfaces where automation specific cabling 
terminates within the automation island. 


broadcast 


A special type of multicast packet that all nodes on the network are always willing to 
receive. [Source: RFC1392] 


broadcast storm 


An incorrect packet broadcast onto a network that causes multiple hosts to respond all 
at once, typically with equally incorrect packets which causes the storm to grow 
exponentially in severity. [Source: RFC1392] 


datagram A self-contained, independent entity of data carrying sufficient information to be 
routed from the source to the destination computer without reliance on earlier 
exchanges between this source and destination computer and the transporting network. 
[Source: RFC1392] 

bulkhead A wall or barrier which maintains the ingress and climatic environmental classification 


applicable on either side 


bulkhead connection 


An assembly of two back-to-back connections separated by a bulkhead 


bulkhead cable gland 


A device at an enclosure bulkhead that provides cable passage for power or signals 


channel A channel is defined as the end-to-end transmission path between two points at which 
application-specific equipment is connected. Alternatively a channel is a path of data 
transfer between two end devices 

Controller CIP connection originator, typically a robot controller or programmable controller 


Quick Connect 


A device mode that allows an EtherNet/IP target device to power up and be ready to 
accept a TCP connection in less than 350ms (for Class A Quick Connect targets). 


encapsulation The technique used by layered protocols in which a layer adds header information to 
the protocol data unit (PDU) from the layer above. As an example, in Internet 
terminology, a packet would contain a header from the physical layer, followed by a 
header from the network layer (IP), followed by a header from the transport layer 
(TCP), followed by the application protocol data. [Source: RFC1208] 

Ethernet A 10-Mb/s standard for LANs, initially developed by Xerox, and later refined by 
Digital, Intel and Xerox (DIX). All hosts are connected to a coaxial cable where they 
contend for network access using a Carrier Sense Multiple Access with Collision 
Detection (CSMA/CD) paradigm. See also: 802.x, Local Area Network, token ring. 
[Source: RFC1392] 

EtherNet/IP Products compliant with this specification as well as the CIP Common specification 
are known as EtherNet/IP products. EtherNet/IP stands for Ethernet Industrial 
Protocol. [Source: RFC1392] 

frame Single data transfer on a link. 

link The physical connection between two active mating components 

MAC ID the 48-bit physical address of an Ethernet node 

network status, Indicators on a node indicating the status of the Physical and Data Link Layers. 

indicators 


network address or 
node address 


A node’s 32-bit TCP/IP address on the link. In most CIP networks, this network 
address is the MAC ID; however, this is not the case on Ethernet. The DLL of 
Ethernet has a 48-bit MAC ID that is not used directly by the CIP communication 
stack. 
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Term 


Definition 


Numerical Aperture 


In optics, the numerical aperture (NA) of an optical system is a dimensionless number 
that characterizes the range of angles over which the system can accept or emit light. 
The exact definition of the term varies slightly between different areas of optics 


physical medium 
dependent 


‘An active interface defined by the appropriate standards to serve a specific medium 
such as copper 2/4 pair or fiber 


physical topology 


The physical layout of devices on a network, or the way that the devices on a network 
are arranged and how they communicate with each other, is called the physical 
topology 


port 


Within the EtherNet/IP specific context, a TCP or UDP port is a transport layer 
demultiplexing value. Each application has a unique port number associated with it. 
[Source: RFC1392]. See CIP Common Specification for an additional definition of 
this term. 


Power over Ethernet 


The delivery of device power along with Ethernet signals, as defined by 803.3an in 
cooperation with TIA-TR42 standards committee 


redundant media 


A system using more than one medium to help prevent communication failures. 


segment 


Trunk—cable sections connected via taps with terminators at each end; a segment has 
no active components and does not include repeaters. 


transceiver 


The physical component within a node that provides transmission and reception of 
signals onto and off of the medium. 
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1-6 Abbreviations 


For the purposes of this standard, the following abbreviations apply. Also see the CIP Common 
Specification Chapter | for additional abbreviations. 


Abbreviation Meaning 

ACD Address Conflict Detection 

AO Automation Outlet 

COTS Commercially off the shelf. Refers to commercial grade components 

DANP Doubly Attached Nodes operating PRP 

FIP File transfer protocol. An internet application that uses TCP reliable packet transfer to move 
file between different nodes. (not to be confused with STP/FTP) 

LAN Local Area Network 

LED Light emitting diode 

LRE Link Redundancy Entity associated with PRP 

NA Numerical Aperture 

PMD Physical Media Dependant 

PoE Power over Ethernet 

POF Polymer Optical Fiber, formerly Plastic Optical Fiber 

PRP Parallel Redundancy Protocol for dual LAN operation 

RCT Redundancy Control Trailer for PRP 

rev Receive 

Red Box PRP Redundancy Box, for attaching non-PRP nodes(s) 

RFC Request For Comments (RFC) — The document series, begun in 1969, which describes the 
Internet suite of protocols and related experiments. Not all (in fact, very few) RFCs describe 
the Internet standards, but all Internet standards are written up as RFCs. The RFC series of 
documents is unusual in that the proposed protocols are forwarded by the Intemet research 
and development community, acting on their own behalf, as opposed to the formally 
reviewed and standardized protocols that are promoted by organizations such as CCITT and 
ANSL [Source: RFC 1392] 

RSTP Rapid Spanning Tree Protocol 

1x Receive 

SAN Singly Attached Node in a PRP topology 

STP/FTP Shielded twisted pair/foil twisted pair 

TCP Transmission Control Protocol (TCP) - An Internet Standard transport layer protocol defined 
in STD 7, RFC 793. It is connection-oriented and stream-oriented, as opposed to UDP. See 
also: connection-oriented, stream-oriented, User Datagram Protocol. [Source: RFC1392] 

Tx transmit 

UDP User Datagram Protocol (UDP) - An Internet Standard transport layer protocol defined in 
STD 6, RFC 768. It is a connectionless protocol which adds a level of reliability and 
multiplexing to IP. See also: connectionless, Transmission Control Protocol. [Source: 
RFC1392] 

UTP Unshielded twisted pair 

Xmit transmit 
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2-2 


Introduction 


This chapter (chapter 2) of the specification documents the method used to encapsulate 
industrial protocols on a TCP/IP network. This mechanism can be applied to the CIP industrial 
protocol or to other networks. Chapter 3 of this specification details the application of this 
encapsulation protocol to CIP. 


Use of TCP and UDP 


The encapsulation protocol defines a reserved TCP port number that shall be supported by all 
EtherNet/IP devices. All EtherNet/IP devices shall accept at least 2 TCP connections on TCP 
port number OxAF12. Once the TCP connection to TCP port number OxAF12 is established, all 
data sent through the TCP stream shall be in the format specified in section 2-3. 


NOTE: TCP is a stream-based protocol. It is permitted to send almost any length IP packet it 
chooses. For example, if two back-to-back encapsulated messages were passed to a TCP/IP 
stack, the TCP/IP stack may choose to put both encapsulated messages in one Ethernet frame. 
Alternately, it may choose to place half of the first message in the first Ethernet frame and all 
the rest in the next Ethernet frame. This is shown in Figure 2-2.1. 


Figure 2-2.1 Usage of TCP to Encapsulate Two Messages 


Two back-to-back encapsulated messages could be 
sent in many different ways by the TCP/IP stack. Two 
examples are given here: 


Ethernet header] IP header | TCP header Encapsulation Encapsulation CRC 
(14 bytes) (20 bytes) (20 bytes) message #1 message #2 
or 
Ethernet header| IP header | TCP header | Start of encapsulation cRC 
(14 bytes) (20 bytes) (20 bytes) message #1 
Ethernet header] IP header | TCP header | Rest of encapsulation Encapsulation CRC 
(14 bytes) (20 bytes) (20 bytes) message #1 message #2 


NOTE: It is not the intention of this specification to document the details of the TCP, UDP and 
IP transport mechanisms. Many excellent resources including the RFCs referenced throughout 
this specification should be used to obtain this information. 


The encapsulation protocol also defines a reserved UDP port number that shall be supported by 
all EtherNet/IP devices. All devices shall accept UDP packets on UDP port number OxAF12. 
Whenever UDP is used to send an encapsulated message, the entire message shall be sent in a 
single UDP packet. Only one encapsulated message shall be present in a single UDP packet 
destined to UDP port OxAFI12. 


Some encapsulated messages shall only be sent via TCP. Other may be sent via either UDP or 
TCP. See “Table 2-3.2 Encapsulation Commands” for details about which commands are 
restricted to TCP. 
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2-3 


2-3.1 


Encapsulation Messages 


Encapsulation Packet Structure 


All encapsulation messages, sent via TCP or sent to UDP port OxAF12, shall be composed of a 
fixed-length header of 24 bytes followed by an optional data portion. The total encapsulation 
message length (including header) shall be limited to 65535 bytes. Its structure shall be as 
follows: 


Table 2-3.1 Encapsulation Packet 


Structure Field Name Data Type Field Value 
Encapsulation | Command UINT Encapsulation command 
header Length UINT Length, in bytes, of the command specific 


data portion of the message, i.e., the number 
of bytes following the header 


Session handle UDINT Session identification (application 
dependent) 
Status UDINT Status code 
Sender Context ARRAY of octet Information pertinent only to the sender of an 
encapsulation command. Length of 8. 
Options UDINT Options flags 
Command Encapsulated data ARRAY of 0 to The encapsulation data portion of the 
specific data 65511 octet message is required only for certain 
commands 


The encapsulation message length shall not override length restrictions imposed by the 
encapsulated protocol. 


Multi-byte integer fields in the encapsulation messages shall be transmitted in little-endian byte 
order. 


NOTE: This is different from the byte ordering used in standard Internet network protocols, 
which is big-endian. 


Although the header contains no explicit information to distinguish between a request and a 
reply, this information shall be determined in either of two ways: 


e implicitly, by the command and the context in which the message is generated. (For 
example, in the case of the RegisterSession command, the request is generated by an 
originator and the target generates the reply); 

e explicitly, by the contents of an encapsulated protocol packet in the data part of the 
message. 
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2-3.2 Command Field 
The allocation of command codes shall be as follows: 


Table 2-3.2 Encapsulation Commands 


Code Name Comment 


0x0000 NOP (may be sent only using TCP) 


0x0001 Reserved for legacy usage | 


0x0002 | Reserved for legacy usage ' 
and 
0x0003 


0x0004 ListServices (may be sent using either UDP or TCP) 


0x0005 Reserved for legacy usage ' 


0x0006 Reserved for future expansion of this specification 
through (Products compliant with this specification shall 


0x0062 not use command codes in this range) 

0x0063 ListIdentity (may be sent using either UDP or TCP) 

0x0064, ListInterfaces optional (may be sent using either UDP or 
TCP) 

0x0065 RegisterSession (may be sent only using TCP) 

0x0066 | UnRegisterSession (may be sent only using TCP) 

0x0067 Reserved for legacy usage : 

through 

0x006E 

0x006F | SendRRData (may be sent only using TCP) 

0x0070 | SendUnitData (may be sent only using TCP) 

0x0071 Reserved for legacy usage! 

through 

Ox00C7 


0x00C8 Reserved for future expansion of this specification 
through (Products compliant with this specification shall 
OxFFFF not use command codes in this range) 


Table Footnotes 

1 Commands marked as “Reserved for legacy usage” indicate commands that were defined prior 
to the publication of this specification. Their behavior is undefined in this specification. Devices 
should not implement these commands without prior knowledge of the legacy usage. Devices 
that do not support these commands shall return encapsulation status code 0x0001. 


A device shall accept commands that it does not support without breaking the session or 
underlying TCP connection. A status code indicating that an unsupported command was 
received shall be returned to the sender of the message. 


NOTE: The establishment of a session is defined in section 2-5. In short, a session makes a 
TCP/IP connection between originator and target over which encapsulated commands may be 
sent. Since TCP/IP connections are modeled as a stream of bytes, the encapsulation header is 
prepended to each encapsulated packet so that the receiving device can know where packets 
begin and end. 
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2-3.3 


2-3.4 


2-3.5 


Length Field 


The length field in the header shall specify the size in bytes of the data portion of the message. 
The field shall contain zero for messages that contain no data. The total length of a message 
shall be the sum of the number contained in the length field plus the 24-byte size of the 
encapsulation header. 


The entire encapsulation message shall be read from the TCP/IP connection even if the length 
is invalid for a particular command or exceeds the host’s internal buffers. Data that would 
exceed internal buffers may be discarded, however the entire encapsulation messages must be 
read. Failure to read the entire message can result in losing track of the message boundaries in 
the TCP byte stream. 


Session Handle 


The Session Handle shall be generated by the target and returned to the originator in response 
to a RegisterSession request. The originator shall insert it in all subsequent encapsulation 
commands (sent using the commands listed in Table 2-3.2) which require sessions to that 
particular target. In the case where the target initiates and sends a command to the originator, 
the target shall include this field in the request that it sends to the originator. 


Some commands (e.g., NOP) do not require a session handle even if a session has been 
established. The description of a particular command will note if it does not require a session. 


Status Field 


The value in the Status field shall indicate whether or not the receiver was able to execute the 
requested encapsulation command. A value of zero in a reply shall indicate successful 
execution of the command. In all requests issued by the sender, the Status field shall contain 
zero. If the receiver receives a request with a non-zero Status field, the request shall be ignored 
and no reply shall be generated. 


NOTE: This field does not reflect errors that are generated by an encapsulated protocol packet 
contained within the data portion of the message. For example, an error encountered during an 
end node's processing of a Set Attributes service would be returned via the CIP specified error 
mechanism (see Volume 1, Chapter 3). 


The status codes shall be as follows: 
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2-3.6 


2-3.7 


2-3.8 


Table 2-3.3 Error Codes 


Status Code Description 
0x0000 Success 
0x0001 The sender issued an invalid or unsupported encapsulation command. 
0x0002 Insufficient memory resources in the receiver to handle the command. This is not an 


application error. Instead, it only results if the encapsulation layer cannot obtain memory 
resources that it needs. 


0x0003 Poorly formed or incorrect data in the data portion of the encapsulation message. 

0x0004 — 0x0063 Reserved for legacy usage ' 

0x0064 An originator used an invalid session handle when sending an encapsulation message to the 
target. 

0x0065 The target received a message of invalid length 

0x0066 — 0x0068 Reserved for legacy usage A 

0x0069 Unsupported encapsulation protocol version. 


Ox006A —OxFFFF | Reserved for future expansion (Products compliant with this specification shall not use 
command codes in this range) 


Table Footnotes 

1 Error codes marked as “Reserved for legacy usage” indicate error codes that were defined prior to the 
publication of this specification. Their usage is undefined in this specification. Devices should not use these 
error codes without prior knowledge of the legacy usage. 


Sender Context Field 


The sender of the command shall assign the value in the Sender Context field of the header. 
The receiver shall return this value without modification in its reply. Commands with no 
expected reply may ignore this field. 


NOTE: The sender of a command may place any value in this field. It could be used to match 
requests with their associated replies. 

Options Field 

The intent of this field is to provide the bits that modify the meaning of the various 
encapsulation commands. Options and option behavior are defined on a per-command basis. 
Command Specific Data Field 


NOTE: The structure of the command specific data field depends on the command code. To 
organize their command specific data field, most commands use either or both of the following 
two methods: 


1) use a fixed structure 
2) use the common packet format (described in section 2-6) 


The common packet format allows commands to structure their command specific data field in 
an extensible way. 
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2-4 


2-4.1 


2-4.2 


2-4.2.1 


Command Descriptions 


NOP 


Either an originator or a target may send a NOP command. No reply shall be generated by this 
command. The data portion of the command shall be from 0 to 65511 bytes long. The receiver 
shall ignore any data that is contained in the message. A NOP command does not require that a 
session be established. 


The NOP encapsulation header shall be as follows: 
Table 2-4.1 NOP Header Values 


Structure Field Name Data Type Field Value 
Encapsulation | Command UINT NOP (0x00) 
heater Length UINT Length of the command specific data 
Session Handle UDINT Any value (ignored by target) 
Status UDINT 0 
Sender Context ARRAY of octet | Chosen by sender. Length of 8. 
Options UDINT 0! 
Command Unused data ARRAY of octet | Any value (ignored by target) 
specific data 


Table Footnotes 


1 For backwards compatibility, no options shall be defined for this command. The receiver shall discard 
packets with a non-zero option field. 


ListIdentity 


General 


A connection originator may use the ListIdentity command to locate and identify potential 
targets. This command shall be sent as a unicast message using TCP or UDP, or as a broadcast 
message using UDP and does not require that a session be established. The reply shall always 
be sent as a unicast message. 


When received as a broadcast message, the receiving device shall delay for a pseudo-random 
period of time prior to sending the reply as specified in section 2-4.2.3. Delaying before 
sending the reply helps to spread out any resulting ARP requests and ListIdentity replies from 
target devices on the network. 
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2-4.2.2 


2-4.2.3 


Request 
The ListIdentity request shall be as shown below: 
Table 2-4.2 ListIdentity Request 


Structure Field Name Data Type Field Value 
Encapsulation | Command UINT ListIdentity (0x63) 
header Length UINT 0 
Session Handle UDINT Any value (ignored by target). 
Status UDINT 0 
Sender Context UINT MaxResponseDelay in milliseconds, see section 2- 
4.2.3. 
ARRAY of 6 Reserved, shall be ignored by the receiver, values 
USINT shall be 0. 
Options UDINT 0! 


Table Footnotes 


1 For backwards compatibility, no options shall be defined for this command. The receiver shall discard 
packets with a non-zero option field. 


Reply 


One reply item is defined for this command, Target Identity, with item type code 0x0C. This 
item shall be supported (returned) by all EtherNet/IP devices. 


A receiver of the List Identity command shall reply with a standard encapsulation header and 
data, as shown below. The data portion of the message shall provide the information on the 
target’s identity. The reply shall be sent to the IP address from which the request was received. 


When the ListIdentity request has been received as a UDP broadcast message, the receiver shall 
delay before sending the reply. When received as a unicast message (either via UDP or TCP), 
the receiver shall not delay. 


The receiver’s delay shall be a random value, in milliseconds, between 0 and the 
MaxResponseDelay specified in the ListIdentity request. If the sender specifies a 
MaxResponseDelay value of 0 ms, a default value of 2000 ms shall be used by the receiver. If 
the sender specifies a MaxResponseDelay value of 1-500 ms, a value of 500 ms shall be used 
by the receiver. A new random value shall be chosen for each request. 


The purpose of the delay is to spread the ListIdentity responses (and the ARP messages that 
may result) over the MaxResponseDelay interval. It is therefore important that each device 
generate a unique random delay value. Devices shall ensure they each generate a unique value, 
for example by seeding their random number generators with a unique value such as their IP 
address or Ethernet MAC address. 


It is possible that devices may receive additional broadcast ListIdentity requests while delaying 
for the response, for example, if multiple clients issue the broadcast ListIdentity request. 
Devices should be able to accept and process at least 2 outstanding broadcast ListIdentity 
requests concurrently. 


After issuing a broadcast ListIdentity request, a client should not issue further requests until the 
MaxResponseDelay interval for its current request has expired. Client behavior for handling 
ListIdentity responses received beyond MaxResponseDelay is vendor specific. 


— 2-10 - 
Edition 1.18 
SINGLE SUBSCRIPTION ONLY; SUBSCRIPTION TERMS AND CONDITIONS OUTLINED ON PAGE (iii) 


Volume 2: EtherNet/IP Adaptation of CIP, Chapter 2: Encapsulation Protocol 


Table 2-4.3 Successful ListIdentity Reply 


Structure Field Name Data Type Field Value 
Encapsulation | Command UINT List Identity (0x63) 
header Length UINT Length of the command specific data 
Session handle UDINT Any value (ignored by receiver). 
Status UDINT 0 
Sender Context ARRAY of octet Value from request. Length of 8. 
Options UDINT 0! 
Command Ttem Count UINT Number of target items to follow 
specific data Target Items STRUCT of Interface Information 
UINT Item ID 
UINT Ttem Length 
ARRAY of octet Item Data 


Table Footnotes 


1 For backwards compatibility, no options shall be defined for this command. The receiver shall discard 
packets with a non-zero option field. 


The data portion of the message shall be the Common Packet Format that contains a 2-byte 
item count followed by an array of items providing the target identity. 


The CIP Identity item defined in Table 2-4.4, shall be the first item returned. Part of this item 
definition follows the Get Attribute All service response definition of the Identity Object (data 
returned based on instance one of this object). Unlike most fields in the Common Packet 
Format, the Socket Address field shall be sent in big endian order. 


At present no additional items are defined for the ListIdentity reply. Additional items may be 
defined in the future. Receivers of the ListIdentity reply shall ignore unexpected items. 
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Table 2-4.4 CIP Identity Item 


Parameter Name Data Type Description 
Item ID UINT Item ID of CIP Identity (Ox0C) 
Ttem Length UINT Number of bytes in item which follow (length varies 
depending on Product Name string) 
Encapsulation Protocol | UINT Encapsulation Protocol Version supported (also returned 
Version with Register Session reply). 
Socket Address STRUCT of Socket Address (see section 2-6.3.2) 
INT sin_family (big-endian) 
UINT 
UDINT sin_addr (big-endian) 
ARRAY of USINT sin_zero (length of 8) (big-endian) 
Vendor ID ' UINT Device manufacturers Vendor ID 
Device Type ! UINT Device Type of product 
Product Code ! UINT Product Code assigned with respect to device type 
Revision | USINT[2] Device revision 
Status | WORD Current status of device 
Serial Number | UDINT Serial number of device 
Product Name ! SHORT_STRING Human readable description of device 
State USINT Current state of device 


Table Footnotes 


1 These parameters are further defined by the corresponding instance attribute of the Identity Object. (see the 
CIP Common specification, chapter 5, Object Library) 


2 The State attribute is an optional attribute of the Identity Object. If not implemented, the value shall be OxFF 


2-4.3 ListInterfaces 


2-4.3.1 General 


The optional List Interfaces command shall be used by a connection originator to identify non- 
CIP communication interfaces associated with the target. A session need not be established to 
send this command. 

2-4,3.2 Request 
The ListInterfaces request shall be as shown below. 


Table 2-4.5 ListInterfaces Request 


Structure Field Name Data Type Field Value 
Encapsulation | Command UINT List Interfaces (0x64) 
header Length UINT 0 
Session Handle UDINT Any value (ignored by target) 
Status UDINT 0 
Sender Context ARRAY of octet Chosen by sender. Length of 8. 
Options UDINT 0! 


Table Footnotes 


1 For backwards compatibility, no options shall be defined for this command. The receiver shall discard 
packets with a non-zero option field. 
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2-4,3.3 


2-4.4 


2-4.4.1 


Reply 


Table 2-4.6 shows the format of the successful ListInterfaces reply. 


Table 2-4.6 Successful ListInterfaces Reply 


Structure Field Name Data Type Field Value 
Encapsulation | Command UINT List Interfaces (0x64) 
header Length UINT Length of the command specific data 
Session Handle UDINT Any value (ignored by receiver). 
Status UDINT 0 
Sender Context ARRAY of octet Value from request. Length of 8. 
Options UDINT 0! 
Command Ttem Count UINT Number of target items to follow 
Specific data [Target Items STRUCT of Interface Information 
UINT Item ID 
UINT Item Length 
ARRAY of octet Item Data 
Table Footnotes 
1 For backwards compatibility, no options shall be defined for this command. The receiver shall discard 
packets with a non-zero option field. 
The data portion of the reply contains an array of items providing interface information. The 
format of the data portion is a 2-byte item count followed by an array of items. At present no 


public items are defined for the ListInterfaces reply. If no items are included, the Item Count 


shall be set to 0. 


Some legacy devices may return “Reserved for legacy usage items” (refer to Section 2-6). 
Such items shall be ignored unless the receiving device has explicit knowledge of the legacy 


format and usage. 
RegisterSession 


General 


An originator shall send a RegisterSession command to a target to initiate a session. The 
RegisterSession command does not require that a session be established. 


NOTE: See section 2-5, for detailed information on establishing and maintaining a session. 
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2-4.4.2 


2-4.4.3 


Request 


The RegisterSession request shall be as follows: 


Table 2-4.7 RegisterSession Request 


Structure Field Name Data Type Field Value 
Encapsulation | Command UINT RegisterSession (0x65) 
header Length UINT 4 
Session Handle UDINT Any value (ignored by target) 
Status UDINT 0 
Sender Context ARRAY of octet Any value. Length of 8. 
Options UDINT 0! 
Command Protocol version UINT 1 
Specific data |" Options flags UINT No options flags are currently defined. 


Session options shall be set to 0. 
NOTE: This field is not the same as the 
option flags in the encapsulation header. 


Table Footnotes 


1 For backwards compatibility, no options shall be defined for this command. The receiver shall discard 


packets with a non-zero option field. 


Reply 


The target shall send a RegisterSession reply to indicate that it has registered the originator. 
have the same format as the request as shown below: 


The reply shal 


Table 2-4.8 Successful RegisterSession Reply 


Structure Field Name Data Type Field Value 
Encapsulation | Command UINT RegisterSession (0x65) 
header Length UINT 4 
Session Handle UDINT Session Handle generated by target 
Status UDINT 0 
Sender Context ARRAY of octet Value from request. Length of 8. 
Options UDINT 0! 
Command Protocol version UINT Version from RegisterSession request if 
specific data supported. If the requested version is not 
supported, contains the highest version supported. 
Options flags UINT Options flags from RegisterSession request if 


supported. If any requested Options flags are not 
supported, contains the supported Options flags. 


Table Footnotes 


1 For backwards compatibility, no options shall be defined for this command. The receiver shall discard 


packets with a non-zero option field. 


The Session Handle field of the header shall contain a target-generated identifier that the 
originator shall save and insert in the Session Handle field of the header for all subsequent 
requests to that target. This field shall be valid only if the Status field is zero (0). 
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2-4.5 


If the originator was successfully registered with the target, the Status field shall be zero (0). If 
the originator was not successfully registered, the Status field shall contain the appropriate 
error code, as follows: 


e Error code 0x0001 shall be returned if the originator attempts to register more than | active 
session on the same TCP connection. 

e Error code 0x0002 shall be returned if the target does not have sufficient resources to 
register the originator. 

e Other error codes from table 2-3.3 may be used as appropriate for general encapsulation 
related errors (e.g., poorly formed encapsulation message, invalid length). 

e Error code 0x0069 shall be returned for Protocol Version or Options mismatches, as 
described below: 


The Protocol Version field shall equal the requested version if the originator was successfully 
registered. If the target does not support the requested version of the protocol, 


e the session shall not be created; 
e the Status field shall be set to ‘unsupported encapsulation protocol’ (0x0069); 
e the target shall return the highest supported version in the Protocol Version field. 


At present, no Options flags are defined. In order to support their future definition, targets 
must check the value of the Options flags in the RegisterSession request. If all requested 
options are supported, the Options field in the reply shall contain the originator's requested 
value. If the target does not support the requested options, 


e the session shall not be created; 
e the Status field shall be set to ‘unsupported encapsulation protocol’ (0x0069); 
e the target shall return the options that it supports in the RegisterSession reply. 


UnRegisterSession 


Either an originator or a target may send this command to terminate the session. The receiver 
shall initiate a close of the underlying TCP/IP connection when it receives this command. The 
session shall also be terminated when the transport connection between the originator and 
target is terminated. The receiver shall perform any other associated cleanup required on its 
end. There shall be no reply to this command, except in the event that the command is received 
via UDP. If the command is received via UDP, the receiver shall reply with encapsulation 
error code 0x01 (invalid or unsupported command). 


The UnregisterSession command format shall be as follows: 


Table 2-4.9 UnregisterSession Command 


Structure Field Name Data Type Field Value 
Encapsulation | Command UINT UnRegisterSession (0x66) 
header Length UINT 0 
Session Handle UDINT Session Handle 
Status UDINT 0 
Sender Context ARRAY of octet Any value. Length of 8 (ignored by 
target). 
Options UDINT 0! 
Table Footnotes 


1 For backwards compatibility, no options shall be defined for this command. The receiver shall discard 
packets with a non-zero option field. 
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2-4.6 


2-4.6.1 


2-4.6.2 


2-4.6.3 


The receiver shall not reject the UnRegisterSession due to unexpected values in the 
encapsulation header (invalid Session Handle, non-zero Status, non-zero Options, or additional 
command data). In all cases the TCP connection shall be closed. 


NOTE: See section 2-5.3 for more detail about terminating a session. 
ListServices 


General 


The ListServices command shall determine which encapsulation service classes the target 
device supports. The ListServices command does not require that a session be established. 


NOTE: Each service class has a unique type code, and an optional ASCII name. 


Request 
The ListServices header shall be as follows: 


Table 2-4.10 ListServices Request 


Structure Field Name Data Type Field Value 
Encapsulation | Command UINT ListServices (0x04) 
header Length UINT 0 
Session Handle UDINT Any value (ignored by target). 
Status UDINT 0 
Sender Context ARRAY of octet Chosen by sender. Length of 8. 
Options UDINT 0! 


Table Footnotes 


1 For backwards compatibility, no options shall be defined for this command. The receiver shall discard 
packets with a non-zero option field. 


Reply 


The receiver shall reply with a standard encapsulation message, consisting of the header and 
data, as shown below. The data portion of the message shall provide the information on the 
services supported. 
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Table 2-4.11 Successful ListServices Reply 


Structure Field Name Data Type Field Value 
Encapsulation | Command UINT ListServices (0x04) 
header Length UINT Length of the command specific data 
Session Handle | UDINT Any value (ignored by receiver). 
Status UDINT 0 
Sender Context | ARRAY of octet Value from request. Length of 8. 
Options UDINT 0! 
Command Ttem Count UINT Number of items to follow 
specific data Target Items STRUCT of Interface Information 
UINT Item ID 
UINT Item Length 
UINT Version of encapsulated protocol shall be set to 1 
UINT Capability flags 
ARRAY of 16 USINT | Name of service 


Table Footnotes 


1 For backwards compatibility, no options shall be defined for this command. The receiver shall discard 
packets with a non-zero option field. 


The Item ID shall identify the service class as follows: 


One service class is defined, with type code 0x100 and name "Communications". This service 
class shall indicate that the device supports encapsulation of CIP packets. All devices that 
support encapsulating CIP shall support the ListServices request and Communications service 
class. 


NOTE: See section 2-6 for a description of items and a list of all reserved item codes. 


The Version field shall indicate the version of the service supported by the target to help 
maintain compatibility between applications. 


Each service shall have a different set of capability flags. Reserved flags shall be set to zero. 
The Capability Flags, defined for the Communications service, shall be as follows: 
Table 2-4.12 Capability Flags 


Flag Value Description 
Bits0-4 Reserved for legacy usage ' 
Bit 5 If the device supports EtherNet/IP encapsulation of CIP this bit shall be set (=1); otherwise, it shall 
be clear (=0) 
Bits 6-7 Reserved for legacy usage ' 
Bit 8 Supports CIP transport class 0 or 1 UDP-based connections 
Bits 9-15 Reserved for future expansion 


Table Footnotes 


1 


Flags marked as “Reserved for legacy usage” indicate flags that were defined prior to the publication of this 
specification. Their usage is undefined in this specification. Devices should not use these flags without prior 
knowledge of the legacy usage. If a device receives a reserved flag that it does not understand, the reply shall be 
processed and the flag ignored. 


The Name field shall allow up to a 16-byte, NULL-terminated ASCII string for descriptive 
purposes only. The 16-byte limit shall include the NULL character. 
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2-4.7 


2-4.7.1 


2-4.7.2 


2-4.7.3 


SendRRData 


General 


A SendRRData command shall transfer an encapsulated request/reply packet between the 
originator and target, where the originator initiates the command. The actual request/reply 
packets shall be encapsulated in the data portion of the message and shall be the responsibility 
of the target and originator. 


NOTE: When used to encapsulate the CIP, the SendRRData request and response are used to 
send encapsulated UCMM messages (unconnected messages). See chapter 3 for more detail. 
Request 

The SendRRData header shall be as follows: 

Table 2-4.13 SendRRData Request 


Structure Field Name Data Type Field Value 
Encapsulation Command UINT SendRRData (Ox6F) 
header Length UINT Length of the command specific data 
Session Handle UDINT Session handle 
Status UDINT 0 
Sender Context ARRAY of octet | Chosen by sender. Length of 8. 
Options UDINT 0! 
Command Interface handle UDINT 0 
specific data | Timeout UINT 0 to 65535 
Encapsulated packet | ARRAY of octet | see Common Packet Format specification in section 2-6) 


Table Footnotes 


1 


For backwards compatibility, no options shall be defined for this command. The receiver shall discard packets with 
a non-zero option field. 


The Interface handle shall identify the Communications Interface to which the request is 
directed. This handle shall be 0 for encapsulating CIP packets. 


The target shall abort the requested operation after the timeout expires. When the “timeout” 
field is in the range 1 to 65535, the timeout shall be set to this number of seconds. When the 
“timeout” field is set to 0, the encapsulation protocol shall not have its own timeout. Instead, it 
shall rely on the timeout mechanism of the encapsulated protocol. 


When the SendRRData command is used to encapsulate CIP packets, the Timeout field shall be 
set to 0, and shall be ignored by the target. 


The encapsulated protocol packet shall be encoded in the Common Packet Format as shown in 
section 2-6. 
Reply 


The SendRRData reply, as shown below, shall contain data in response to the SendRRData 
request. The reply to the original encapsulated protocol request shall be contained in the data 
portion of the SendRRData reply. 


— 2-18 - 
Edition 1.18 
SINGLE SUBSCRIPTION ONLY; SUBSCRIPTION TERMS AND CONDITIONS OUTLINED ON PAGE (iii) 


Volume 2: EtherNet/IP Adaptation of CIP, Chapter 2: Encapsulation Protocol 


Table 2-4.14 Successful SendRRData Reply 


Structure Field Name Data Type Field Value 
Encapsulati_ | Command UINT SendRRData (0x6F) 
on header | Tength UINT Length of the command specific data 
Session handle UDINT Value from request. 
Status UDINT 0 
Sender Context ARRAY of octet Value from request. Length of 8. 
Options UDINT 0! 
Command Interface handle UDINT 0 
spoon Timeout UINT 0 to 65535 (ignored) 
Encapsulated packet | ARRAY of octet see Common Packet Format specification in section 2-6) 


Table Footnotes 


1 For backwards compatibility, no options shall be defined for this command. The receiver shall discard packets with 
a non-zero option field. 


The format of the data portion of the reply message shall be the same as that of the 
SendRRData request message. 


NOTE: Since the request and reply share a common format, the reply message contains a 
timeout field; however, it is not used. 


2-4.8 SendUnitData 


The SendUnitData command shall send encapsulated connected messages. This command may 
be used when the encapsulated protocol has its own underlying end-to-end transport 
mechanism. A reply shall not be returned. The SendUnitData command may be sent by either 
end of the TCP connection. 


NOTE: When used to encapsulate the CIP, the SendUnitData command is used to send CIP 
connected data in both the O>T and T>0 directions. 


The format of the SendUnitData command shall be as follows: 
Table 2-4.15 SendUnitData Command 
Structure Field Name Data Type Field Value 
Encapsulati_ | Command UINT SendUnitData (0x70) 
onheader | Tength UINT Length of data portion 
Session Handle UDINT Session handle 
Status UDINT 0 
Sender Context ARRAY of octet Any value. Length of 8 (ignored by target). 
Options UDINT 0! 
Command Interface handle UDINT shall be 0 
specific | Timeout UINT shall be 0 
Encapsulated packet | ARRAY of octet see Common Packet Format specification in section 2-6) 


Table Footnotes 


1 For backwards compatibility, no options shall be defined for this command. The receiver shall discard packets with 
a non-zero option field. 


Interface handle and Timeout shall be set the zero. The timeout field is not used since no reply 
is generated upon receipt of a SendUnitData command. 
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2-5 Session Management 


2-5.1 Phases of a TCP Encapsulation Session 
An encapsulation session shall have three phases: 


e establishing a session; 
e maintaining a session; 
e closing a session. 


2-5.2 Establishing a Session 
Session establishment shall proceed according to the following steps: 


e The originator shall open a TCP/IP connection to the target, using the reserved TCP port 

number (OxAF12), or if specified, the TCP port number from the connection path (the 

means to specify an alternate TCP port number is described in chapter 3); 

e The originator shall send a RegisterSession command to the target (see section 2-4.4 for a 

description of the RegisterSession command); 

e The target shall check the protocol version in the command message to verify it supports 

the same protocol version as the originator. If not, the target shall return a RegisterSession 

reply with the appropriate Status field along with the highest supported protocol version; 

e The target shall check the options flags in the command to verify that it supports the 

requested options. If not, the target shall return a RegisterSession reply with the 

appropriate Status field along with the options it supports. 

e The target shall assign a new (unique) Session ID and shall send a RegisterSession reply to 
the originator. 


Originators shall register no more than one active session on a single TCP connection. 


2-5.3 Terminating a Session 


Either the originator or the target may terminate the session. Sessions shall be terminated in 
either of two ways: 


e The originator or target shall close the underlying TCP connection. The corresponding 
target or originator shall detect the loss of the TCP connection, and shall close its side of 
the connection; 

e = The originator or target shall send an UnRegisterSession command (see section 2-4.5 for a 
description of the UnregisterSession command) and shall wait to detect the closing of the 
TCP connection. The corresponding target or originator shall then close its side of the TCP 
connection. The sender of the UnRegisterSession shall detect the loss of the TCP 
connection, then it shall close its side of the connection. 


NOTE: The second method is preferred since it results in more timely cleanup of the TCP 
connection. 

2-5.4 Maintaining a Session 
Once a session is established, it shall remain established until one of the following occurs: 


e the originator or target closes the TCP connection; 
e the originator or target issues the UnRegisterSession command; 
e the TCP connection is broken. 
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2-5.5 


2-5.5.1 


2-5.5.2 


TCP Connection Management 


TCP Behavior (informative) 


TCP is a reliable, connection-oriented protocol. If a process at either end of a connection 
closes its end of the connection, the TCP at the other end is notified immediately. If a message 
from one process to the other cannot be delivered in a reasonable amount of time, the 
connection is assumed to be broken and an error is returned to the sender on all subsequent 
sends and receives on the connection. 


If an originator process detects that a target has closed its end of a connection or that a 
connection is broken, it assumes the session with the target is broken and closes its connection 
to the target. A new session is then established as described above in order to resume 
communications with the target. 


Although an originator process is notified when the other end of a connection has been closed, 
a broken connection can only be detected when a process actually attempts to send a message 
over the connection. In most cases, the originator process sends messages to targets frequently 
enough that a crash of a target machine is detected in a timely manner. Likewise, targets send 
messages back to originators frequently enough that terminated originator processes and 
originator machine crashes are detected quickly. However, it is possible that an originator or 
target may not have any messages to send on a connection for a relatively long period of time. 


The TCP protocol supports keep-alive processing. An application can ask TCP to make sure 
the connection remains working during periods when the application does not have any 
messages to send. If this feature is enabled, when the connection has been idle for some period 
of time, TCP will send a keep-alive message to its peer at the other end of the connection. If 
TCP sends several keep-alive messages and does not receive a reply, TCP assumes the 
connection has broken and the application is notified just as if it had sent an actual message that 
timed out. 


Most implementations of TCP/IP retry/timeout processing do not declare a failure on a 
connection until it has remained unusable for several minutes. This is a feature of the TCP 
protocol on the originator host; turning keep alives does not modify it. 


TCP Connection Management for EtherNet/IP 


In order to send CIP unconnected messages, or to open a CIP connection, the originator must 
first open a TCP connection with the target. After a period of no Encapsulation activity on a 
TCP connection (see Encapsulation Inactivity Timeout attribute of the TCP/IP Interface Object 
in Chapter 5, which defines this period), originators and targets shall close the TCP connection. 
Encapsulation activity is defined as: 


° Encapsulation commands of any type, including NOP, sent or received 
° Outstanding UCMM request that has not timed out or received a reply 
. Open transport class 2 or class 3 connection 

Notice that TCP keep-alive traffic does not count as Encapsulation activity. 


Devices shall implement the TCP inactivity behavior described above and shall also implement 
the Encapsulation Inactivity Timeout attribute of the TCP/IP Interface Object (see Chapter 5), 
which defines a default inactivity timeout and a means to change the inactivity timeout. 
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2-6 


2-6.1 


In the condition where a target’s CIP connections from an originator all time out, the target 
shall close the TCP connection from that originator immediately. The purpose of this behavior 
is to help prevent half-open CIP connections that can result from TCP retries at the originator 
due to link-lost conditions. 


Both targets and originators shall maintain a pool of TCP connections that are dedicated to 
EtherNet/IP. The purpose of maintaining a separate pool is to prevent other services such as 
HTTP from consuming all TCP connections and starving EtherNet/IP traffic. 


Common Packet Format 


General 


The common packet format (CPF) defines a standard format for protocol packets that are 
transported with the encapsulation protocol. The common packet format is a general-purpose 
mechanism designed to accommodate future packet or address types. 


The common packet format shall consist of an item count, followed by a number of items. 
Some items are classified as “address items” (carries addressing information) or “data items” 
(carries encapsulated data). The number of items to be included depends on the encapsulation 
command and usage of the command. Section 2-6.4 specifies the valid Common Packet Format 
items for the various commands and usages. 


Table 2-6.1 Common Packet Format 


Field Name Data Type Description 
Ttem count UINT Number of items to follow 
Item #1 Item Struct (see below) Ist CPF item 
Ttem #2 Ttem Struct (see below) 2nd CPF item 
Ttemn Ttem Struct (see below) nth CPF item 


The address and data item structure shall be as follows: 


Table 2-6.2 CPF Item Format 


Field Name Data Description 
Type 
Type ID UINT Type of item encapsulated 
Length UINT Length in bytes of the Data Field 
Data Variable The data (if length >0) 
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Table 2-6.3 Item ID Numbers 


Item ID number Item type Description 

0x0000 address Null (used for UCMM messages). Indicates that encapsulation routing is NOT 
needed. Target is either local (Ethernet) or routing info is in a data Item. 

0x0001 — 0x000B Reserved for legacy usage ' 

0x000C ListIdentity response 

0x000D — 0x0085 Reserved for legacy usage ' 

0x0086 — 0x0090 Reserved for future expansion of this specification (Products compliant with this 
specification shall not use command codes in this range) 

0x0091 Reserved for legacy usage ' 

0x0092 —0x00A0 Reserved for future expansion of this specification (Products compliant with this 
specification shall not use command codes in this range) 

OxAl address Connection-based (used for connected messages) 

Ox00A2 —0Ox00A4 Reserved for legacy usage ' 

Ox00A5 —0x00B0 Reserved for future expansion of this specification (Products compliant with this 
specification shall not use command codes in this range) 

0x00B1 data Connected Transport packet 

Ox00B2 data Unconnected message 

0x00B3 - OxOOFF Reserved for future expansion of this specification (Products compliant with this 
specification shall not use command codes in this range) 

0x0100 ListServices response 

0x0101 —0x010F Reserved for legacy usage ' 

0x01 10 — Ox7FFF Reserved for future expansion of this specification (Products compliant with this 
specification shall not use command codes in this range) 

0x8000 data Sockaddr Info, originator-to-target 

0x8001 data Sockaddr Info, target-to-originator 

0x8002 Sequenced Address item 

0x8003 — OxFFFF Reserved for future expansion of this specification (Products compliant with this 


specification shall not use command codes in this range) 


Table Footnotes 

1 Items marked as “Reserved for legacy usage” indicate Item IDs that were defined prior to the publication of this 
specification. Their behavior is undefined in this specification. Devices should not use these Item IDs without prior 
knowledge of the legacy usage. 


2-6.2 Address Items 


2-6.2.1 Null Address Item 


The null address item shall contain only the type id and the length as shown below. The length 
shall be zero. No data shall follow the length. Since the null address item contains no routing 
information, it shall be used when the protocol packet itself contains any necessary routing 
information. The null address item shall be used for Unconnected Messages. 


Table 2-6.4 Null Address Item 


Field Name Data Field Value 
Type 
Type ID UINT | 0 
Length UINT | 0 
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2-6.2.2 


2-6.2.3 


2-6.3 


2-6.3.1 


2-6.3.2 


Connected Address Item 


This address item shall be used when the encapsulated protocol is connection-oriented. The 
data shall contain a connection identifier. 


NOTE: Connection identifiers are exchanged in the Forward_Open service of the Connection 
Manager. 


Table 2-6.5 Connected Address Item 


Field Name Data Field Value 
Type 
Type ID UINT | OxAI 
Length UINT 4 
Data UDINT | Connection Identifier 


Sequenced Address Item 


This address item shall be used for CIP transport class 0 and class 1 connected data. The data 
shall contain a connection identifier and an Encapsulation Sequence Number. 


Table 2-6.6 Sequenced Address Item 


Field Name Data Field Value 
Type 
Type ID UINT 0x8002 
Length UINT 8 
Data UDINT | Connection Identifier 
UDINT | Encapsulation Sequence Number 


Data Items 


Unconnected Data Item 
The data item that encapsulates an unconnected message shall be as follows: 


Table 2-6.7 Unconnected Data Item 


Field Name Data Field Value 
Type 
Type ID UINT OxB2 
Length UINT Length, in bytes, of the unconnected message 
Data Variable | The unconnected message 


NOTE: The format of the “data” field is dependent on the encapsulated protocol. When used 
to encapsulate CIP, the format of the “data” field is that of a Message Router request or 
Message Router reply. See chapter 3 of this specification for details of the encapsulation of 
UCMM messages. See Volume 1, Chapter 2 for the format of the Message Router request and 
reply packets. 


The context field in the encapsulation header shall be used for unconnected request/reply 
matching. 
Connected Data Item 


The data item that encapsulates a connected transport packet shall be as follows: 
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Table 2-6.8 Connected Data Item 


Field Name Data Field Value 
Type 
Type ID UINT OxB1 
Length UINT Length, in bytes, of the transport packet 
Data Variable | The transport packet 


NOTE: The format of the “data” field is dependent on the encapsulated protocol. When used 
to encapsulate CIP, the format of the “data” field is that of connected packet. See chapter 3 of 
this specification for details of the encapsulation of connected packets. See chapter 3 of the 
CIP Specification (Volume 1) for the format of connected packets. 


2-6.3.3 Sockaddr Info Item 


The Sockaddr Info items shall be used to communicate IP address or port information 
necessary to create Class 0 or Class 1 connections. There are separate items for originator-to- 
target and target-to-originator socket information. The items are present as additional data in 
Forward_Open / Large_Forward_Open request and reply services encapsulated in a 
SendRRData message. Volume 2, Chapter 3-3.9 describes the usage of these items in the 
context of creating CIP connections. 


The Sockaddr Info items shall have the following structure: 
Table 2-6.9 Sockaddr Item 


Field Data Type Field Value 
Name 
Type ID UINT 0x8000 for OT, 0x8001 for TO 
Length UINT 16 (bytes) 
sin_family | INT shall be AF_INET = 2. This field shall be sent in big endian order. 
sin_port UINT For point-point connections, sin_port shall be set to the UDP port to which packets for 


this CIP connection will be sent. For point-point connections, it is recommended that the 
registered UDP port (Ox8AE) be used. 


When used with a multicast connection, the sin_port field shall be set to the registered 
UDP port number (Ox08AE) and treated by the receiver as “don’t care”. 
This field shall be sent in big endian order. 


sin_addr UDINT For multicast connections, sin_addr shall be set to the IP multicast address to which 
packets for this CIP connection will be sent. When used with a point-point connection, 
the sin_addr field shall be treated by the receiver as “don’t care”. It is recommended that 
the sender set sin_addr to 0 for point-point connections. This field shall be sent in big 
endian order. 


sin_zero ARRAY of USINT | Length of 8. Recommended value of zero; not enforced 


NOTE: The structure of the Sockaddr item has been patterned after the sockaddr_in structure 
rom the Winsock specification, version 1.1. 
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2-6.4 Valid Common Packet Format Item Usage Summary 
The Common Packet Format is used with the following encapsulation commands: 
e —ListIdentity reply 
e = ListInterfaces reply 
e —ListServices reply 
e SendRRData request and reply 
e =SendUnitData 
e Transport class 0 and class | packets (no encapsulation header) 
Table 2-6.10 shows the valid usage of CPF items for the various encapsulation commands. 
Note that Chapter 3 of this volume contains the detailed formats and usage for CIP connected 
and unconnected messages. 
Table 2-6.10 Usage of CPF items 
Action if unexpected or 
Command Required CPF Items Optional CPF Items undefined CPF items are 


present 


Listldentity reply 


ListIdentity reply item 


None. 


Ignore items. 


ListInterfaces 
reply 


None. 


Legacy devices may return ‘Reserved 
for legacy usage’ items. 


Ignore items. 


ListServices reply 


ListServices item for the 
“Communications” service. 


Legacy devices may return ‘Reserved 
for legacy usage’ items. 


Ignore items. 


SendRRData Address item followed by When used to encapsulate the Return error (0x0003) 
request Data item. Forward_Open service, additional 
Sockaddr_info items may be present, 
as specified in Chapter 3. 
SendRRData Address item followed by When used to encapsulate the Signal error to the calling 
reply Data item. Forward_Open reply, additional application. For 
Sockaddr_info items may be present, Forward_Open reply, 
as specified in Chapter 3. connection shall not be 
established at the originator. 
SendUnitData Address item followed by None. Discard message. 
Data item 
Class 0/1 packet | Address item followed by None. Discard message. 
Data item 
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to TCP/IP 


3-2.1 


Introduction 


This chapter (chapter 3) of the EtherNet/IP specification describes the application of the 
encapsulation in chapter 2 to the Common Industrial Protocol (CIP). Specifically, this chapter 
documents the encapsulation of the UCMM and connected packets; extends the format of the 
path to include IP addresses; and limits which CIP transport parameters can be used in 
combination. 


CIP Packets over TCP/IP 


When the path of a CIP packet traverses an Ethernet-TCP/IP network, the encapsulated packet 
shall be transmitted using the TCP/IP protocol suite and the encapsulation protocol defined in 
chapter 2. 


Unconnected Messages 


UCMM packets shall be transmitted over a TCP/IP connection, using the encapsulation 
protocol defined in chapter 2. A UCMM request shall be formatted as shown in Table 3-2.1. 


Table 3-2.1 UCMM Request 


Structure Field Name Data Type Field Value 
Encapsulation Command UINT SendRRData (Ox6F) 
header Length UINT Length of command specific data 
portion 
Session handle UDINT Handle returned by RegisterSession 
Status UDINT 0 
Sender Context ARRAY of 8 | Chosen by sender 
octet 
Options UDINT 0 
Command Interface handle UDINT 0 
specific data Timeout UINT Any value (ignored by target) 
Encapsulated Item count UINT 2 (indicates 1 address item, 1 data 
packet item) 
. Address Type | UINT 0 (Null Address Item) 
(in the Common ID 
Packet Format) 
Address UINT 0 
Length 
Data UINT 0x00B2 (Unconnected Data Item) 
Type ID 
Data Length UINT Length of the next field in bytes 
(length of the MR request packet) 
MR request ARRAY of This field contains a CIP Message 
packet USINT Router request packet as defined in 
Volume 1, Chapter 2. 
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Likewise, the UCMM reply shall be formatted as shown in Table 3-2.2. 
Table 3-2.2 UCMM Reply 


Structure Field Name Data Type Field Value 
Encapsulation Command UINT SendRRData (Ox6F) 
header Length UINT Length of command specific data 
portion 
Session handle UDINT Handle returned by RegisterSession 
Status UDINT 0 
Sender Context ARRAY of 8 | copied from the corresponding UCMM 
octet request 
Options UDINT 0 
Command Interface handle UDINT 0 
specific data Timeout UINT Any value (ignored by receiver) 
Encapsulated Ttem count UINT 2 (indicates 1 address item, 1 data item) 
packet ‘Address Type | UINT 0 (Null Address Item) 
ID 
(in the Common 
Packet Format) Address UINT 0 
Length 
Data UINT 0x00B2 (Unconnected Data Item) 
Type ID 
DataLength | UINT Length of the next field in bytes (length 
of the MR response packet) 
MR response ARRAY of This field contains a CIP Message 
packet USINT Router reply packet as defined in 


Volume 1, Chapter 2. 


Note: Chapter 2 (Encapsulation Protocol) defines the valid format for the SendRRData and 
other encapsulation commands. 


The maximum size of the MR request and MR response packet items in the SendRRData 
command is 504 bytes (the maximum size on ControlNet), to ensure that a UCMM message 
can traverse all the links in a CIP network path. Devices may support the Large_Forward_Open 
service (see Volume |, Chapter 3) to allow more efficient access to large application data sizes. 


When a target receives a SendRRData greater than the maximum size, it shall return an error 
response with encapsulation error code 0x65 (target received a message of invalid length). 
Error code 0x03 is allowed for existing implementations but shall be considered to be 
“deprecated”. New implementations shall use 0x65. 


CIP Transport Class 0 and Class 1 Connections 


NOTE: Please see Volume | for the definition and usage of CIP transport class 0 and class 1 


connections. 
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CIP transport Class 0 and Class 1 Packets 


Packets for CIP transport class 0 and class 1 connections shall be transmitted using UDP. 
Packets for multicast connections shall be transmitted using IP multicast. The packet shall be 
formatted as shown in Table 3-2.3. Note that the packets use the Common Packet Format 
defined in Chapter 2, but without the encapsulation header. 


Table 3-2.3 UDP Data Format for Class 0 and Class 1 


Field Name Type Value 
Ttem Count UINT 2 
Type ID UINT 0x8002 (Sequenced Address Type) 
Length UINT 8 
Address Data UDINT Connection ID (from Forward_Open reply) 


UDINT Encapsulation Sequence Number. Note: this is different 
from the CIP Sequence Count in the transport class 1 
packet. Refer to section 3-4.1. 


Type ID UINT Ox00B1 (Connected Data Type) 
Length UINT Number of bytes in packet to follow 
Data Transport class 0 or class 1 packet as defined in Volume 1. 


Behavior of Class 0 and Class 1 Connections (informative) 


Since Ethernet does not have a mechanism for sending scheduled data, several important 
aspects of class 0 and class 1 behavior are noted as follows: 


On Ethernet, it is possible for a CIP transport class 0 or class 1 connected data packet to be lost, 
for example due to excessive collisions. By definition, class 0 and class | connections do not 
guarantee the delivery of every packet. Rather, producers simply send data at the specified rate 
(the API). If a packet is lost on a class 0 or class 1 connection, the consumer receives the next 
packet from the producer. 


The degree to which lost packets can be tolerated is application-specific. Ethernet is not 
suitable for those applications that cannot tolerate any lost packets. 


Packet loss can be detected by examining the Encapsulation Sequence Number. See section 3- 
4.1, CIP Transport Class 0 and Class | Packet Ordering, for details on the Encapsulation 
Sequence Number, including considerations for out-of-order packets, which will also result in 
gaps in the Encapsulation Sequence Number. 


The connection timeout mechanism provides feedback to the application when too many 
packets are lost. The connection timeout is determined by the Requested Packet Interval (RPI) 
and by the Connection Timeout Multiplier. If a packet is not received in the time specified by 
the RPI times the Connection Timeout Multiplier, the connection is broken. For example, if 
the RPI is 50 ms and the Connection Timeout Multiplier is 4, then the connection will time out 
if a fresh packet is not received in 200 ms (the equivalent of 4 packets being lost). Receipt of 
older packets (those with equal or lower Encapsulation Sequence Numbers) will not sustain the 
CIP connection. 


The degree of packet loss for any particular connection will be dependent upon many factors 
related to the user's Ethernet network configuration. It is beyond the scope of this specification 
to address this in further detail. 


~3-6— 
Edition 1.18 
SINGLE SUBSCRIPTION ONLY; SUBSCRIPTION TERMS AND CONDITIONS OUTLINED ON PAGE (iii) 


Volume 2: EtherNet/IP Adaptation of CIP, Chapter 3: Mapping of Explicit and I/O Messaging 


to TCP/IP 


3-2.2.3 


3-2.3 


No Dependency on TCP Connections 


In order to open a CIP transport class 0 or 1 connection, a TCP connection and an EtherNet/IP 
encapsulation session must first be established. The TCP connection is used to send the 
Forward_Open service and receive the Forward_Open response. Once the TCP connection is 
opened, and CIP transport class 0 and | connections are established, it is recommended that 
EtherNet/IP devices leave the TCP connection open. If the TCP connection is left open, it is 
then available for subsequent communications such as a Forward_Close or other explicit 
messages. 


Although it is recommended that devices leave the TCP connection open, the transport class 0 

and class 1 connections shall not be dependent upon the TCP connection to remain open. If the 
TCP connection closes, the class 0 and 1 connections shall remain open, unless they otherwise 
time out according to their network connection parameters. 


Section 2-5.5.2, TCP Connection Management for EtherNet/IP, contains additional information 
on TCP connection management for EtherNet/IP. 
CIP Transport Class 2 and Class 3 Connections 


CIP transport class 2 and class 3 connected data shall be sent over a TCP connection, using the 
SendUnitData encapsulation command. The connected data shall be formatted as shown in 
Table 3-2.4. 


Table 3-2.4 Transport Class 2 and Class 3 Connected Data 


Structure Field Name Data Type Field Value 
Encapsulation Command UINT SendUnitData (0x70) 
header Length UINT Length of command specific data 
portion 
Session handle UDINT Handle returned by RegisterSession 
Status UDINT 0 
Sender Context ARRAY of 8 | Any value (ignored by target) 
octet 
Options UDINT 0 
Command Interface handle UDINT 0 
specific data Timeout UINT Any value (ignored by target) 
Encapsulated Ttem count UINT 2 (indicates 1 address item, 1 data item) 
packet Address Type | UINT OxA1 (Connected Address item) 
ID 
(in the Common 
Packet Format) Address UINT 4 
Length 
Address Data | UDINT Connection ID from 
Forward_Open/Forward_Open_Reply 
Data UINT 0x00B1 (Connected Data item) 
Type ID 
Data Length UINT Length of the next field in bytes (i.e., 


length of the transport class 2/3 PDU, 
including the CIP Sequence Count). 


Data ARRAY of The transport class 2/3 PDU (including 
USINT the CIP Sequence Count) as defined in 
Volume 1. 
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Multiple CIP connections may be sent over a single TCP connection. An implementation need 
not support a specific number of CIP connections per TCP connection. An implementation 
may impose an upper bound if it chooses. 


Because of the full-duplex nature of TCP, the CIP originator to target (OT) and CIP target to 
originator (TO) link connections shall use the same TCP connection. However if a target 
subsequently originates a CIP connection, then it shall be considered an originator, and a 
different TCP connection shall be used. 


NOTE: This standard defines no requirements for management of the TCP connection, such as 
inactivity timeouts, or closing the TCP connection when all native connections are closed. 
However, implementations are free to implement these. 


Targets and originators shall close any CIP transport class 2 or 3 connections when the 
corresponding originating TCP connection is closed. 
3-2.4 CIP Transport Classes 4 Through 6 


The encapsulation protocol described in chapter 2 shall not be used to encapsulate CIP 
transport classes 4, 5 and 6. 
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3-3 Connection Manager Object 


3-3.1 Connection Parameters 
NOTE: This section documents the Connection Manager parameters that have requirements 


specific to the TCP/IP encapsulation. Connection Manager parameters are fully described in 
Volume 1, Chapter 3. 


3-3.2 Connection Type 
The CIP connection type shall be NULL, MULTICAST, or POINT2POINT. The 


MULTICAST connection type shall be supported only for CIP transport class 0 and class 1 
connections. 


3-3.3 Priority 
Volume 1, Chapter 3 defines 4 levels of CIP priority: LOW, HIGH, SCHEDULED, URGENT, 


with URGENT being the highest priority. Section 3-7 defines Quality of Service (QoS) 
behavior with respect to the different CIP priority levels. 


3-3.4 Trigger Type 


The CIP trigger type shall be CYCLIC, CHANGE_OF_STATE, or APPLICATION. CIP 
transport class 0 and class 1 connections that use CHANGE_OF_STATE triggering shall use 
the Production Inhibit Time segment (see Volume 1). 


3-3.5 Connection Size 
The CIP connection size shall be no larger than 65511 bytes. 


NOTE: The Forward_Open request limits the connection size to 511 bytes; however, the 
optional Large_Forward_Open allows larger connection sizes. 


3-3.6 Connection Request Timeout 


To reliably establish a CIP connection that extends onto a TCP/IP link, the connection request 
time-out shall be large enough to allow the connection to be established, which could involve 
resolving a host name, or going through multiple gateways. 


Because of the large variation in connection request processing over TCP/IP, CIP routers in the 
connection path shall not subtract anything from the connection request timeout. 


3-3.7 Connection Path 


The link address portion of a TCP/IP connection path segment shall be encoded within a port 
segment as a string of ASCII characters. The following forms shall all be supported: 


e JP address in dotted decimal notation, for example “130.151.132.55” (see RFC 1117 for the | 
format of IP addresses); 

e IP address in dotted decimal notation, followed by a":" separator, followed by the TCP | 
port number to be used at the specified IP address; 

e Host name, for example “plc.controlnet.org”. The host name shall be resolved via a DNS 
request to a name server (see RFC 1035 for information on host names and name 
resolution); 
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me 


e Host name, followed by a '":" separator, followed by the TCP port number to be used at the 
specified host. 


The client generating the path shall specify all numbers supplied as parts in IP dotted decimal 
notation as decimal values with no leading “Ox” or “0”. Server handling of leading “Ox” or “0” 
is implementation dependent. 


The port number shall be represented in either hex or decimal. Hex shall be indicated by a 
leading "Ox". When a port number is specified, it shall be used rather than the standard port 
number used for the encapsulation protocol (OXAF12). Only port OxAF12 is guaranteed to be 
available in an EtherNet/IP compliant device. 


NOTE: Other TCP port numbers may be implemented; however, this specification does not 
provide a mechanism to determine which TCP port numbers are supported by a device. The 
use of other TCP port numbers is therefore discouraged. The guaranteed TCP port number, 
OxAF12, has been reserved with the Internet Assigned Numbers Authority (IANA) for use by 
the encapsulation protocol. 


Since port segments must be word-aligned, a pad byte may be required at the end of the string. 
The pad byte shall be 0x00, and shall not be counted in the Optional Address Size field of the 
port segment. 


NOTE: Examples of port segments are shown in Table 3-3.1 (see Volume 1. Section C-1.4.1 
Port Segment, for the definition of a port segment). 


Table 3-3.1 TCP/IP Link Address Examples 


Port Segment IP address Notes 
12][0D 130.151.132.1 Multi-byte address for port 2, 13 
[31][33][30][2E] byte string plus a pad byte 
31)(35][3 1][2E) 
31)(33][32][2E][3 1][00] 
13][12 ple.controlnet.org Multi-byte address for port 3, 18 
70)[6C][63][2E byte string, no pad byte 
63) [6F][6E][74][72][6F][6C][6E][65][74] 
2E. 
6F)(72][67 
16][15 130.151.132.55:0x3210 Multi-byte address for port 6, 21 
31)[33][30][2E! byte string plus a pad byte 
31)(35][31][2E) 
31)[33][32][2E! 
35)[35][3A 
30)(78][33][32][3 1 ][30][00] 
15][17 ple.controlnet.org:9876 Multi-byte address port 5, 23 byte 
70)[6C][63][2E] string plus a pad byte 
63) [6F][6E][74][72][6F][6C][6E][65][74] 
2E. 
6F][72][67][3A. 
39][38][37][36][00] 


Network Connection ID 


General 


For EtherNet/IP connections, the Network Connection ID shall be a 32-bit identifier 
meaningful to the device that chooses it. The Network Connection ID need not be subdivided 
into any specific fields. 
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In general, the consuming device selects the Network Connection ID for a point-to-point 
connection, and the producing device selects the Network Connection ID for a multicast 
connection. The following table shows which device, Target or Originator, shall choose the T- 
>O and O->T Network Connection IDs: 


Table 3-3.2 Network Connection ID Selection 


Connection Type Which Network Connection ID Who chooses Connection ID 
Point-to-point Originator -> Target Target 
Target -> Originator Originator 
Multicast Originator -> Target Originator 
Target -> Originator Target 


The Network Connection ID shall not be reused until the connection has been closed or has 
timed out. When a device restarts, it shall not reuse Network Connection IDs from previously 
opened connections until those connections have been closed or have timed out. A specific 
connection ID shall not be reused so long as there is the possibility that packets with that 
connection ID are present in the network. 


The following two sections describe possible methods to implement unique Network 
Connection IDs. 


Using an Incarnation ID (informative) 


This section describes one solution that prevents Connection ID reuse when a device restarts. 
With this solution, the Ethernet device generates Connection IDs for class 0 and class 1 
connections with format shown in Figure 3-3.1. 


Figure 3-3.1 Connection ID with Incarnation ID 


Incarnation ID Connection Number 


Where: 


Connection Number is a 16-bit identifier meaningful to the device choosing the Connection ID. 


Incarnation ID is a 16-bit identifier that each device generates before accepting or initiating 
any connections. 


The Incarnation ID persists while the device is powered up and accepting connections. Each 
successive power-up cycle must cause a new (unique) Incarnation ID to be generated. The 
following are acceptable methods for generating Incarnation ID's: 


Devices may generate a unique Incarnation ID by saving the Incarnation ID in non-volatile 
storage: when the device powers up, it reads the Incarnation ID from non-volatile storage. This 
is the Incarnation ID to use for the current cycle. It then increments the Incarnation ID and 
stores it for the next cycle. Note, however, that non-volatile memory devices generally have a 
limit to the number of times the device may be written. Depending on the device, it may not be 
feasible to write the Incarnation ID each powerup. 


Devices may generate a unique Incarnation ID by generating a pseudo-random number at 
powerup. This approach requires care. By definition, there is a non-zero probability that the 
generated Incarnation ID is the same as the previous one. However, if done wisely, the 
probability is small enough to not be a concern. 
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Devices such as workstations, because of the large variation in startup time, can safely use the 
value of the system clock as an Incarnation ID. However, for embedded devices, using the 
system clock is not reliable since the firmware generally goes through the exact same sequence 
of instructions at each powerup. This results in the same clock value at the point where it 
would be selected for the Incarnation ID. For these embedded devices, the Incarnation ID 
needs to be generated based on random inputs. This is best done using a pseudo-random 
number generator such as the MDS algorithm. 


Pseudo-Random Connection ID Per Connection (informative) 


This section describes another solution that prevents Connection ID reuse when a device 
restarts. With this solution, the device generates a pseudo-random Connection ID each time a 
class 0 or class 1 Connection ID is needed. The Connection ID format for this approach is 
shown in Figure 3-3.2. 

Figure 3-3.2 Pseudo-Random Connection ID 


Pseudo-Random Number Connection Number 


EEE | 


Where: 


Connection Number is a 16-bit identifier meaningful to the device choosing the Connection ID. 


Pseudo-Random Number is a 16-bit number generated using an appropriate pseudo-random 
number generator. 


With this approach, the device generates the Pseudo-Random Number portion each time a 
Connection ID is needed. A "strong mixing function" such as the MDS algorithm [RFC 1321] 
[RFC 1750] should be used to generate the pseudo-random number. Such functions take 
multiple input and produce pseudo-random outputs. 


In order to prevent Connection IDs from being reused across powerups, the seed values for the 
inputs to the MDS algorithm must be unique across successive powerup cycles. The 
recommended approach is to use the following inputs upon receiving the first incoming 
connection request: 


e Vendor ID, Serial Number, Connection Serial Number 

e Contents of the sockaddr_in struct (for the next hop if outbound connection; of the sender 
if inbound connection) 

e Value of system clock 


NOTE: This assumes the Ethernet device is a bridge or the Target of the connection and would 
not be applicable if the device is the connection Originator. For connection originators, the 
above seed values would likely be the same across successive powerups. Connection 
originators must use another source for initial seed values, or else use the Incarnation ID 
approach. 


By definition, there is a non-zero probability that a Connection ID conflict may still occur. 
However, the probability is lowered by: 


Using a robust pseudo-random number generator such as the MDS algorithm. 


Ensuring the seed values are different on successive power-up cycles. 
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3-3.9.1 


3-3.9.2 


3-3.9.3 


3-3.9.4 


Forward_Open for CIP Transport Class 2 and Class 3 Connections 


The Forward_Open service for CIP class 2 and class 3 connections shall be sent over a TCP 
connection using the SendRRData command defined in chapter 2. Sockaddr Info items 
included within a Forward_open or Forward_open_reply packet that establishes a class 2 or 
class 3 connection shall be ignored. When Sockaddr Info items are included, it is recommended 
that the sender set the sin_port and sin_addr fields set to 0. 


Forward_Open for CIP Transport Class 0 and Class 1 Connections 


Use of TCP for Class 0 and Class 1 Forward_Open 


The Forward_Open service for CIP transport class 0 and class 1 connections shall be sent over 
a TCP connection using the SendRRData command defined in chapter 2. 


General Use of Sockaddr Info Items 


As part of the Forward_Open dialog, the producer and consumer shall exchange the UDP port 
numbers and IP multicast address (for multicast connections) necessary to send the CIP 
transport class 0 and class 1 connected data. The Sockaddr Info item defined in Chapter 2 shall 
be used to encode the UDP port numbers and IP multicast address. The inclusion and use of a 
Sockaddr Info item varies depending on whether the connection is multicast or point-to-point, 
and whether the connection originator or the connection target is the multicast producer. 


Sockaddr Info Item Placement and Errors 


The Sockaddr Info item(s) shall be placed after the Forward_Open and/or Forward_Open_reply 
data in the SendRRData command/reply. It shall be considered an error if a Sockaddr Info item 
is not present for a multicast connection, does not have the correct sin_family value of 
AF_INET = 2, or specifies field values which are illegal for the intended usage. 


The receiver of a Forward_open_request shall return a Forward_open_reply with a status code 
OxO1 and extended status 0x205 (Parameter error in unconnected service) for Sockaddr Info 
items containing errors specified in the preceding paragraph. The receiver of a 
Forward_open_reply containing any Sockaddr Info items with errors shall consider the entire 
reply to be in error. 


Use of Sockaddr Info Item for Multicast Connections 


For multicast connections, the multicast producer shall choose an IP multicast address to which 
to send the connected data. The port number shall be the registered UDP port number 
(Ox08AE) assigned by the IANA. The multicast consumer shall receive the connected data on 
the registered port number. A Sockaddr Info item shall be sent with the Forward_open (if the 
O->T Connection Type is multicast), or with the Forward_open_reply (if the T->O 
Connection Type is multicast). The chosen IP multicast address shall be encoded via the 
sin_addr field of the Sockaddr Info item. The sin_port field of the Sockaddr Info item shall be 
set to OxO8AE and treated by the receiver as “don’t care”. 
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Use of Sockaddr Info Item for Point-Point Connections 


For point-point connections, the point-point consumer shall choose a UDP port number on 
which it will receive the connected data. The point-point producer shall send the connected 
data to the port number chosen by the point-point consumer. It is recommended that the 
consumer use the registered port number (OxO08AE), however the consumer may alternatively 
choose a different port number. 


Note: using a port number other than Ox08AE has potential implication for Quality of Service 
(QoS) configuration and management in infrastructure devices. Switches that have been 
configured to prioritize packets with port number Ox8AE may not prioritize EtherNet/IP 
packets with a different port number. 


If the point-point consumer chooses a port number that is different than OxO8AE, then the 
point-point consumer shall send a Sockaddr Info item indicating the chosen port number. The 
Sockaddr Info item shall be sent with the Forward_open (if the T->O Connection Type is 
point-point), or with the Forward_open_reply (if the O->T Connection Type is point-point). 
The sin_port field of the Sockaddr Info item shall contain the port number selected by the 
consumer. The sin_addr field of the Sockaddr Info item shall be treated as a “don’t care” by the 
receiver of the Forward_open or Forward_open_reply. It is recommended that the sender set 
the sin_addr field to zero. 


If the point-point consumer elects to use the registered port OxO8AE to receive connected data, 
the consumer is not required to send a Sockaddr Info item. The consumer may optionally 
include a Sockaddr Info item as described in the preceding paragraph, with sin_port field 
containing the registered port number. 


For a point-point connection the sin_addr field of the Sockaddr Info item shall be treated as a 
“don’t care” by the receiver of the Forward_open or Forward_open_reply. It is recommended 
that the sender set the sin_addr field to zero. 


Usage Summary of Sockaddr Info for Class 0 or Class 1 Connections 


‘able 3-3.3 shows the usage of Sockaddr Info items in transport class 0 and 1 Forward_Open 
and Forward_Open response. In the cases where the item is “ignored if present”, devices shall 
not check the contents of the Sockaddr Info item for validity. 
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3-3.10 


Table 3-3.3 Sockaddr Info Usage 


Connection Type Service Sockaddr Info items 


O->T ignored if present 
Forward_Open Siete 


Point-Point O->T T->O ignored if present 
Multicast T->O Forward_Open O->T item optional (registered port number used if item is not present) 
response T->O item required 


O->T it ired 
Forward_Open item require 


Multicast O->T T->O item optional (registered port number used if item is not present) 
Point-Point T->O Forward_Open O->T ignored if present 
response T->O ignored if present 


O->T i -d if present 
Forward_Open ignored if present 


Point-Point O->T T->O item optional (registered port number used if item is not present) 
Point-Point T->O Forward_Open O->T item optional (registered port number used if item is not present) 
response T->O ignored if present 


O->T it ired 
Forward_Open paca eae 


Multicast O->T T->O ignored if present 
Multicast T->O. Forward_Open O->T ignored if present 
response T->O item required 


Mapping Connections to IP Multicast Addresses 


NOTE: It is recommended, though not required, that producers use a unique IP multicast 
address for each active multicast connection. Depending upon the implementation, this can 
reduce the amount of connection screening on the part of the consumer. It also allows the 
consumer to more evenly service incoming connected data from multiple connections. 


Since a unique IP multicast address per multicast connection is not required, consumers shall 
be able to handle the situation in which packets from multiple multicast connections are being 
sent to the same IP multicast address. Consumers shall be able to screen the incoming packets 
based on the Connection ID and source IP address. 


NOTE: Requirements for screening connected data are defined in section 3-4.2. 


Completing the Multicast Connection (informative) 


After receiving the Forward_Open_reply the consuming Ethernet devices should join the 
desired IP Multicast Group in order to receive the IP Multicast datagrams. The exact method 
for doing this depends on the TCP/IP application programming interface in use on the device. 


Forward_Close 


In addition to the Forward_Close verification that is specified in Volume 1, section 3-5.5.4, 
EtherNet/IP targets and CIP routers must verify that the IP address of the sender matches the IP 
address of the sender that opened the connection. If the IP address does not match, the target or 
router shall return an error with a General Status code of OxOF (Privilege Violation). The target 
or router shall also increment the “Close Other Rejects” instance attribute of the Connection 
Manager Object, if the attribute is implemented. 
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3-4.1 


CIP Transport Class 0 and Class 1 Connected Data 


CIP Transport Class 0 and Class 1 Packet Ordering 


NOTE: By definition, CIP class 0 and class | transports do not detect out-of-order packets. 
For class 0, every packet is considered to be new data. For class 1, only duplicate data is 
detected. A received packet is considered to be new data whenever the CIP Sequence Count is 
different (either greater or lesser) than the previous packet’s CIP Sequence Count. 


NOTE: When using UDP to transport CIP class 0 and class 1 connected data, there is no 
guarantee that packets arrive in the same order that they were sent. When both sender and 
receiver are on the same subnet, packets typically arrive in order. However, when going 
through routers, when there are multiple paths that a packet could take, it is possible for packets 
to arrive out of order. 


For class 0 and class 1 connections over EtherNet/IP, devices shall maintain an Encapsulation 
Sequence Number in the UDP payload defined in section 3-2.2.1. The Encapsulation Sequence 
Number shall be maintained per connection. Each time an EtherNet/IP device sends a CIP 
class 0 and class | packet, it shall increment the Encapsulation Sequence Number by | for that 
connection. It shall increment even if the CIP Sequence Count (in the class 1 case) has not 
changed. If the receiving EtherNet/IP device receives a packet whose Encapsulation Sequence 
Number is less than or equal to the previously received packet, the packet with the smaller or 
the same Encapsulation Sequence Number shall be discarded. 


Packets shall also be discarded if the Encapsulation Sequence Number is greater than the last 
received and accepted Encapsulation Sequence Number plus the Allowed Sequence Number 
Gap. The Allowed Sequence Number Gap is defined to be the larger of the following two 
values: 


e §=616, or 


e Connection Timeout Multiplier plus 1. The Connection Timeout Multiplier is defined in 
Volume 1, section 3-5.5.1.6, Connection Timeout Multiplier. 


Discarded packets shall not serve to keep the connection alive. 


When targets and originators begin producing data on a transport class 0 or | connection, a 
random initial Encapsulation Sequence Number shall be used. 


The Encapsulation Sequence Number shall be operated on with modular arithmetic to deal with 
sequence rollover. The following paragraph from RFC793 (the TCP definition) describes 
considerations for 32-bit TCP sequence numbers and also applies to the 32-bit Encapsulation 
Sequence Numbers: 


“It is essential to remember that the actual sequence number space is finite, though very 
large. This space ranges from 0 to 2**32 - 1. Since the space is finite, all arithmetic 
dealing with sequence numbers must be performed modulo 2**32. This unsigned 
arithmetic preserves the relationship of sequence numbers as they cycle from 2**32 - 1 to 0 
again. There are some subtleties to computer modulo arithmetic, so great care should be 
taken in programming the comparison of such values. The symbol "=<" means "less than or 
equal" (modulo 2**32).” [RFC 793 sec 3.3] 
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Example macros show how this may be done for Encapsulation Sequence Numbers: 


pe 

* Encapsulation Sequence Numbers are unsigned 32 bit integers operated 

* on with modular arithmetic. These macros can be used to compare such integers. 
#/. 


#define SEQ_LT(a,b) — ((int)((a)-(b)) < 0) 
#define SEQ_LEQ(a,b) ((int)((a)-(b)) <= 0) 
#define SEQ_GT(a,b) _((int)((a)-(b)) > 0) 
#define SEQ_GEQ(a,b) ((int)((a)-(b)) >= 0) 


3-4.2 Screening Incoming Connected Data 


Ethernet devices that receive class 0 and class 1 connected data shall screen incoming packets 
based on the network connection ID and IP address of the sending device. This is necessary for 
the following reasons: 


e For multicast connections, there is no guaranteed mechanism to prevent multiple devices 
from using the same IP multicast address. Consequently, a device could receive (bogus) 
multicast connected data from a device with which it has not established a connection. 

e For multicast connections, a device is allowed to use the same IP multicast address for 
multiple class 0 and class 1 multicast connections. 

e To prevent network connection ID conflicts. 


When a class 0 or class 1 connection is established, the target and originating Ethernet devices 
shall record the network connection ID on which they will receive connected data, coupled 
with the IP address of the device at the other end of the connection. When a device receives 
connected data, it shall confirm that the network connection ID is valid for the IP address of the 
sending device. If not, the packet shall be discarded. 
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3-5 
3-5.1 


3-5.1.1 


3-5.1.2 


3-5.1.3 


IP Multicast Scoping and Address Allocation 
Background (informative) 


General 


Two issues related to IP multicast must be considered when implementing EtherNet/IP 
multicast connections: IP multicast scoping and IP multicast address allocation. 


IP multicast scoping refers to the practice of limiting how widely a given multicast datagram is 
propagated across the network. IP multicast address allocation refers to the problem of how 
applications select IP multicast addresses that are used to send and receive IP multicast 
datagrams. 


The following subsections on multicast scoping and allocation practices are informative, and 
are intended to set the general context for considering the issues of scoping and address 
allocation. Specific requirements for EtherNet/IP devices follow in subsequent sections. 


IP Multicast Scoping Practices 


In general, most currently deployed networks use the practice of “TTL scoping” in conjunction 
with router and/or switch configuration to confine multicast traffic to desired network 
boundaries. 


TTL scoping refers to the practice of using the “Time to Live” (TTL) field in the IP header to 
limit the number of network hops over which the multicast packet is propagated. When 
sending an IP multicast datagram, a host can set the TTL field in the IP header to an 
appropriate value based on how widely the datagram should be propagated. As the datagram is 
routed through the network, each hop decrements the TTL field. Routers can be configured 
with TTL thresholds such that they will not forward a packet unless the TTL is greater than the 
threshold. 


Note that a multicast datagram with an initial TTL of 1 limits the datagram to the local subnet. 
Other common TTL values are 16 for multicast within a site and 64 for multicast within a 
region. 


In addition to TTL scoping, multicast routing protocols and other methods are commonly used 
to control the propagation of multicast traffic. Routers commonly support multicast protocols 
such as PIM, DVMRP, etc. Switches that implement “IGMP snooping” can limit the multicast 
packets sent on a port to only those multicast addresses for which the end device has issued an 
IGMP membership message. Configuration of switches and routers is usually done by 
knowledgeable staff. 


IP Multicast Address Allocation Practices 


The entire IP multicast address space is 224.0.0.0 through 239.255.255.255. The Internet 
Assigned Numbers Authority (www.iana.org) is responsible for allocation of the IP multicast 
address space. IP multicast addresses have been assigned to particular organizations, and for 
particular protocols. In addition there is a large block of IP multicast addresses allocated for 
“administratively scoped” multicast, from which applications may allocate addresses, and for 
which a suite of allocation and scoping protocols are being developed by the Internet 
Engineering Task Force (IETF). The administratively scoped range is from 239.0.0.0 through 
239.255.255.255 (and is further partitioned into additional ranges). 
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3-5.2 


3-5.3 


Unfortunately at present there are no widely deployed standard mechanisms for allocating and 
assigning multicast addresses to applications. For example, when a network administrator 
deploys a video streaming application, the application will have its own specific mechanism for 
assigning IP multicast addresses. 


Multicast Scoping for EtherNet/IP 


By default, EtherNet/IP devices shall use a TTL equal to 1 for transport class 0 and 1 multicast 
packets. The use of a TTL value of | prevents multicast packets from propagating beyond the 
local subnet. When TTL is equal to 1, both the EtherNet/IP producer and consumer must be on 
the same subnet. 


EtherNet/IP devices are strongly encouraged to support the explicit configuration of the TTL 
value for IP multicast packets. If supported, devices shall use the TCP/IP Interface Object 
(class OxF5) as the mechanism to configure the TTL value. When a TTL value greater than 1 is 
configured, then the producer and consumer may be on different subnets. 


If the TTL value has not been configured to be greater than | and if a multicast connection 
request is received from an originator on a different subnet, then the device shall return General 
Status 0x01 and Extended Status 0x813 in the Forward_Open Reply. 


When the TTL value is explicitly configured, it shall be used for all EtherNet/IP multicast 
packets. 


Multicast Address Allocation for EtherNet/IP 


EtherNet/IP defines two mechanisms for allocation of IP multicast addresses used for 
EtherNet/IP multicast packets: using an algorithm based on the device’s IP address, and 
explicit configuration via the TCP/IP Interface Object. EtherNet/IP devices shall implement the 
algorithm-based method by default. Devices are also strongly encouraged to implement the 
method for explicit configuration of multicast addresses. Both methods are described below: 


1. Allocation algorithm based on the device’s IP address: 


The overall IP multicast address range shall be the Organizational Local Scope, and shall 
start at 239.192.1.0. Each device shall use a block of (at most) 32 multicast addresses from 
this range. Each device shall calculate the block of multicast addresses via an algorithm, 
described further below, that uses the Host Id portion of the device’s IP address. 


A device’s Host Id shall be determined by applying the subnet mask to the device’s IP 
address. If a subnet mask is configured for the device, the subnet mask shall be applied to 
the IP address to determine the Host Id. If no subnet mask is in use, then the class of the 
device’s IP address shall be used to determine the Host Id (e.g., for Class C addresses 8 bits 
of Host Id shall be used, for Class B addresses 16 bits of host id shall be used, and for Class 
A addresses 24 bits of Host Id shall be used). 


In order to keep the IP multicast addresses within the IPv4 Organization Local Scope, and 
to put a reasonable bounds on the number of multicast addresses in use, devices shall use at 
most the low-order 10 bits of the Host Id in generating the range of multicast addresses. 
This allows for 1024 unique Host Ids. 
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The following pseudo-code shows the algorithm to determine the device’s starting and 
ending multicast addresses: 


CIP_Mcast_Base_Addr = OxEFC00100 // 239.192.1.0 is the starting address 
CIP_Host_Mask = 0x3FF // 10 bits of host id 


if Subnet_mask configured then 
Netmask = Subnet_mask 
else 
if IP_address is Class A then 
Netmask = 255.0.0.0 
else if IP_address is Class B then 
Netmask = 255.255.0.0 
else if IP_address is Class C then 
Netmask = 255.255.255.0 
end_else 


Host_id = IP_addr & (~Netmask) 
Mcast_index = Host_id - 1 
Mcast_index = Mcast_index & (CIP_Host_Mask) 


Mcast_start_addr = CIP_Mcast_Base_Addr + (Mcast_index * 32) 
Mcast_end_addr = Mcast_start_addr + 31 


The following table shows example multicast assignments. 


Subnet mask IP address Multicast addresses 

None configured 192.168.1.1 239.192.1.0 - 239.192.1.31 

(8 bits of Host Id used, since | 192.168.1.2 239.192.1.32 - 239.192.1.63 

192.168.x.x is Class C) 192.168.1.3 239,192.1.64 - 239.192.1.95 
10.10.16.1 239.192.1.0 - 239.192.1.31 
10.10.16.2 239.192.1.32 - 239.192.1.63 

255.255.248.0 10.10.16.3 239.192. 1.64 - 239.192.1.95 

(11 bits of Host Id) 10.10.20.0 239.192.128.224 - 239.192.128.255 
(Host Id = 1024; lower 10 | (this is the highest multicast address range that 
bits all 0) would result using the algorithm) 


Since there are a finite number of unique Host Ids, it is possible for different devices to 
produce data using the same multicast address. Consequently, devices that receive packets 
on EtherNet/IP multicast connections shall screen the incoming packets based on the CIP 
Connection Id as well as the IP address of the sending device. This is described in Chapter 
3-4.2. 


Note that when the device’s IP address or subnet mask changes, the IP multicast addresses 
generated by the algorithm also shall change accordingly. 


2. Explicit configuration of IP multicast addresses: 


IP multicast addresses are configured via the TCP/IP Interface Object (class OxF5). The 
user (or software) can configure a starting multicast address and number of multicast 
addresses to allocate. The configured multicast addresses shall then be used for EtherNet/IP 
multicast packets. 


EtherNet/IP devices shall at least implement the algorithmic method for allocating IP multicast 
addresses, and are encouraged to implement both methods. If both methods are implemented, 
the algorithmic method shall be the default “out of box” method. 
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3-5.4 


3-5.5 


User Considerations (informative) 


This section is informational, and is meant to be an aid to vendors and users in the practical 
deployment of EtherNet/IP applications. When deploying an EtherNet/IP system that uses 
multicast connections, the user should consider a number of aspects in order to achieve 
satisfactory application performance. 


1. When devices allocate IP multicast addresses according to the default algorithm in section 
3-6.3, the assignment of IP addresses to devices affects the way that IP multicast addresses 
are selected. Users should be aware that only 10 bits the IP address are used to generate 
the Host Id, which in turn determines the device’s range of IP addresses. If the user’s 
subnet mask is larger than 10 bits, there is the potential for multiple devices to use the same 
IP multicast address when producing data. While this does not result in incorrect 
operation, it can result in devices experiencing performance degradation due to the receipt 
of additional multicast packets that must be discarded. 


2. When multicast addresses are explicitly configured, care should be taken so that devices in 
the same subnet have unique blocks of multicast addresses. Further, if multicast 
connections will cross subnet boundaries, then care must be taken to ensure that all devices 
in the network have unique blocks of multicast addresses. When configuring multicast 
addresses, it is recommended that addresses from the IPv4 Local Scope be used 
(239.255.0.0 — 239.255.255.255) so as not to conflict with multicast address that may be 
generated algorithmically. 


3. Some routers experience performance degradation when they must handle many multicast 
packets with TTL equal to 1. In such situations, users may configure TTL to be greater 
than | even though I/O connections do not need to cross subnets. When setting TTL 
greater than 1, it is recommended that users also configure multicast addresses for each 
device. If multicast addresses are not explicitly configured, they are generated according to 
the algorithm in the specification. Care must be taken in this situation since devices in 
different subnets could generate the same IP multicast addresses. The multicast packets 
sent from one subnet would then be received on the other subnet, possibly impacting 
performance. In order to prevent unwanted multicast propagation, the user must perform 
additional router configuration to constrain the EtherNet/IP multicast packets to the subnet 
on which they originate. There are several techniques for constraining multicast at the 
router. Router configuration is beyond the scope of this specification. 


4. Users are strongly recommended to use switches that implement IGMP snooping. When 
IGMP snooping is used, devices will only receive the multicast packets in which they are 
interested (i.e., for which they have issued an IGMP membership message). 


Future Directions for EtherNet/IP (informative) 


There are a number of Internet standards regarding IP multicast allocation and scoping. While 
these standards have not yet been widely deployed, they are expected to have an impact on 
future EtherNet/IP mechanisms for using IP multicast. Three RFC’s that seem most relevant to 
EtherNet/IP are listed below: 


e “The Internet Multicast Address Allocation Architecture”, RFC 2908 
e “Administratively Scoped Multicast”, RFC 2365 
e “Multicast Address Dynamic Client Allocation Protocol (MADCAP)”, RFC 2730 
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3-6.1 


3-6.2 


IGMP Usage 


Background (informative) 


The Internet Group Management Protocol (IGMP) is a standard protocol used by hosts to 
report their IP multicast group memberships and must be implemented by any host that wishes 
to receive IP multicast datagrams. IGMP messages are used by multicast routers to learn which 
multicast groups have members on their attached networks. IGMP messages are also used by 
switches capable of supporting “IGMP snooping” whereby the switch listens to IGMP 
messages and only sends the multicast packets to ports that have joined the multicast group. 


There are three versions of IGMP: 


e IGMP V1 is defined in RFC1112. 
e IGMP V2 is defined in RFC2236. 
e IGMP V3 is defined in RFC3376. 


RFC2236 and RFC3376 discuss host and router requirements for interoperation with older 
IGMP versions. 


Since EtherNet/IP devices make extensive use of IP multicast for CIP transport class 0 and 1 
connections, consistent IGMP usage by EtherNet/IP devices is essential in order to create well- 
functioning EtherNet/IP application networks. 


IGMP Membership Report Messages 


EtherNet/IP devices shall issue a Membership Report message (V1, V2 or V3 as appropriate) 
when opening a CIP connection on which they will receive multicast packets. Specifically, 
devices shall adhere to the following behavior: 


1. When the T->O Connection Type is multicast (originator is multicast consumer), the 
originator shall issue a Membership Report upon receipt of a successful 
Forward_Open_reply. The Membership Report shall include the IP multicast address as 
communicated in the Forward_Open_reply. 


2. When the O->T Connection Type is multicast (target is multicast consumer), the target 
shall issue a Membership Report upon sending a successful Forward_Open_reply. The 
Membership Report shall include the IP multicast address as communicated in the 
Forward_Open. 


If the device has already issued a Membership Report for the IP multicast address (e.g., if the 
multicast address is being used with an existing connection) the device may, but is not required 
to, issue another Membership Report. 


Devices shall also send Membership Report messages in response to Membership Query 
messages, per the IGMP RFCs. 
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3-6.3 IGMP Leave Group messages 


Devices that support IGMP V2 shall issue a Leave Group when all the CIP connections 
associated with a consuming IP multicast address have either closed or timed out. Specifically, 
devices shall adhere to the following behavior: 


1. When the T->O Connection Type is multicast (originator is multicast consumer), the 
originator shall issue a Leave Group upon receipt of a successful Forward_Close reply if 
the originator has no other open connections consuming on that IP multicast address. 


2. When the O->T Connection Type is multicast (target is multicast consumer), the target 
shall issue a Leave Group upon sending a successful Forward_Close reply if the target has 
no other open connections consuming on that IP multicast address. 


3. In the event of a connection timeout, the multicast consumer (whether target or originator) 
shall issue a Leave Group message if the multicast consumer has no other connections 
consuming on that IP multicast address. 
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3-7 


3-7.1 


Quality of Service (QoS) for EtherNet/IP Messages 


Overview of QoS for EtherNet/IP 


Quality of Service (QoS) is a general term for mechanisms that treat traffic streams with 
different relative priorities or other delivery characteristics. Standard QoS mechanisms include 
IEEE 802.1D/Q (Ethernet frame priority) and Differentiated Services (DiffServ) in the TCP/IP 
protocol suite. 


Within the CIP and EtherNet/IP application context, QoS is especially important for time 
sensitive applications such as CIP Sync and CIP Motion where packet delivery will affect 
application stability. 


EtherNet/IP defines requirements and recommendations for how EtherNet/IP devices use two 
standard QoS mechanisms: 802.1D/Q and Differentiated Services. The following summarizes 
the QoS mechanisms defined for EtherNet/IP devices: 


e The overall approach is for EtherNet/IP end devices to mark EtherNet/IP packets with 
priority values, using the standard mechanisms mentioned above. Marking packets with 
priority enables infrastructure devices (e.g., switches and routers) to better differentiate 
EtherNet/IP traffic. 

e For CIP transport class 0 and | connections (i.e., UDP-based), there is a defined mapping 
of CIP priorities to 802.1D priorities and DiffServ Code Points (see section 3-7.5). 

e For UCMM and CIP transport class 2 and 3 connections (i.e., TCP-based), and all other 
EtherNet/IP encapsulation messages (both TCP-based and UDP-based), there is a defined 
DiffServ Code Point and 802.1D priority value. 

e For PTP (IEEE 1588) messages, there are DiffServ Code Points and 802.1D priority values 
corresponding to the two different types of PTP messages. 

e It is strongly recommended that devices by default mark CIP and PTP messages with 
DSCP values. 

e In addition to DSCP, devices may optionally support sending and receiving 802.1Q tagged 
frames. If supported, sending tagged frames shall be disabled by default in order to prevent 
device interoperability problems. When 802.1Q tagging is desired, the end user must 
explicitly enable the sending of 802.1Q frames, and must ensure that both the sending and 
receiving devices support tagged frames. 

e ~The QoS Object provides a means to configure DSCP values, and a means to 
enable/disable sending of 802.1Q tagged frames (see Volume 2, Chapter 5). 

e There are no requirements for devices to mark traffic other than CIP or IEEE 1588. 
Devices may do so, depending on their implementation capabilities. 

e At present there are no specific implementation requirements for end devices to internally 
differentiate traffic with different priorities. Traffic differentiation in end devices is an area 
of future development. EtherNet/IP implementations are at a minimum recommended to 
give higher priority to processing EtherNet/IP implicit messages over explicit messages. 
Further differentiation based on the above QoS mechanisms, where possible, is also 
recommended. 
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3-7.2 


3-7.3 


3-7.4 


QoS References 

The following list shows the references applicable to QoS for EtherNet/IP devices 

e RFC 2474 — Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 
Headers 

e RFC 2475 — An Architecture for Differentiated Services 

e RFC 2597 — Assured Forwarding PHB Group 

e RFC 2873 — TCP Processing of the IPv4 Precedence Field 

e RFC 3140 — Per Hop Behavior Identification Codes 

e RFC 3246 - An Expedited Forwarding PHB (Per-Hop Behavior) 

e RFC 4594 — Configuration Guidelines for DiffServ Service Classes 

e IEEE Std 802.1D — 2004 (defines the use of priority in the 802.1Q frame format) 

e JEEE Std 802.1Q — 2005 (defines VLAN operation including the tagged frame format) 


DSCP Format 


Differentiated Services (DiffServ) is a model for specifying the relative priority of traffic based 
on the type of service (ToS) field of an IPv4 packet. The model is defined in RFC 2475. 
DiffServ allows nodes to route packets based on class of traffic as defined by the DiffServ 
Codepoint (DSCP) and the defined Per-Hop Behavior (PHB) characteristics. 

Figure 3-7.1 shows the DS field in the IP header. 

Figure 3-7.1 DS Field in the IP Header 


IPV4 Packet 


Version 
Length 


TOS. Len ID Offset TTL 


Octets 


Bits 6 2 
Note that when setting the DSCP value in the IP header, if placed directly in the ToS field, it 
must be shifted left 2 bits. 
IEEE 802.1D/Q format 


TEEE 802.1Q defines an Ethernet frame format that allows inclusion of VLAN ID and priority. 
The 802.1Q frame has EtherType of 0x8100 and a 4-byte prefix between the Source and Type 
fields of the frame. The tagged frame defines a 3-bit field to specify 8 priority levels, further 
specified in 802.1D. Priority 7 is the highest. Priority 0 is the lowest. 


Figure 3-7.2 shows the format of an 802.1Q frame. 
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Figure 3-7.2 802.1Q Tagged Frame 
Tag 
Ethernet frame ( \ 
SFD DST SRC | 0x8100 Control 0x800 | re 
Octets 1 6 6 2 2 2 
Priority 
| Bits 0 VLAN ID 
Bits ‘re 12 
3-7.5 Mapping CIP Traffic to DSCP and 802.1D 


Table 3-7.1 defines the default DSCP and 802.1D priority mappings for EtherNet/IP and CIP 
Syne (IEEE 1588) traffic. 


Table 3-7.1 Default DSCP and 802.1D Mapping for EtherNet/IP 


Traffic Type CIP Priority DSCP 802.1D Priority’ CIP Traffic Usage (recommended) 
PTP Event 59 
na 7 n/a 
(IEEE 1588) CIL1011’) 
PTP General (IEEE iva 47 5 nla 
1588) C1011’) : 
Cihelass 01 Urgent (3) oo 6 CIP Motion 
(10111) 
Safety VO 
Scheduled (2) #1 5 eth 
C101111’) vO 
: 43 
High (1 5 vo 
igh (1) 101011") 
Low (0) 31 3 No recommendation at present 
CO1LI11’) 
CIP UCMM 
CIP class 2/3 
27 Ssast 
All other EtherNet/IP All CouOL) 3 CIP messaging 
encapsulation 
messages 


Table Footnotes 
1 Sending 802.1Q tagged frames is disabled by default 


In Table 3-7.1 above, note that the 802.1D and DSCP values for transport class 0 and class 1 
messages are based on the CIP priority (indicated in the Forward Open service). PTP and CIP 
explicit messages use 802.1D and DSCP values independent of CIP priority. 


The default DSCP values and 802.1Q tagged frame enable/disable may be changed via the QoS 
Object (see chapter 5). 


Note: The default DSCP values are “local use” values, as defined in RFC 2474. 
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3-7.6 


3-7.7 


3-7.8 


EtherNet/IP usage of DSCP 


When marking EtherNet/IP traffic with DSCP values, EtherNet/IP devices shall use the values 
as configured in the QoS Object (default values are shown in Table 3-7.1). Usage of the ECN 
field in the IP header by EtherNet/IP end devices is not currently defined and shall be set to 0. 


Notice that when DSCP marking is supported, all outgoing packets for established TCP. 
encapsulation connections shall be marked with the appropriate DSCP value, including ACK- 
only packets. It is recommended that all outgoing packets involved in the opening and closing 
of these connections also be marked (SYN, FIN, RST, and associated ACKs). 


Devices are strongly encouraged to support marking EtherNet/IP packets with DSCP values. 
When supported, the default behavior shall be to mark packets. 


All EtherNet/IP devices shall support receiving packets with non-zero DSCP values since this 
is an Internet Protocol requirement (see RFC 791 and RFC 1122). Note that Ethernet 
infrastructure devices (e.g., switches and routers) can potentially alter DSCP values. Receiving 
devices shall not assume or otherwise check that incoming DSCP values are the same as in 
Table 3-7.1 above, or are the same values as sent from the sending device. This behavior is 
consistent with modifications to TCP (RFC 793) as described by RFC 2873. 


EtherNet/IP usage of 802.1D/Q 


When sending traffic with 802.1Q tagged frames, EtherNet/IP devices shall use the priority 
values specified in Table 3-7.1. The VLAN ID shall be set to 0, unless a specific VLAN ID for 
the device has been configured by means not covered by this specification. When receiving 
802.1Q tagged frames, devices shall not require that the VLAN ID be set to 0. 


When sending 802.1Q tagged frames, devices shall also set the corresponding DSCP value in 
the IP header. 


When 802.1Q frames are supported, the device shall also support the QoS Object (see Chapter 
5). The default behavior shall be to disable sending of 802.1Q tagged frames, since sending 
tagged frames by default can result in device interoperability problems. 


Notice that when sending traffic with 802.1Q tagged frames, all outgoing packets for 
established TCP encapsulation connections shall use the specified 802.1D priority value, 
including ACK-only packets. It is recommended that all outgoing packets involved in the 
opening and closing of these connections (SYN, FIN, RST, and associated ACKs) also use the 
same 802.1D priority value. 


User considerations with 802.1D/Q 


Some EtherNet/IP devices do not support receiving 802.1Q tagged frames. When 802.1Q 
frames are sent to such devices, the frames will be dropped. In addition, some managed 
switches will drop 802.1Q tagged frames unless the receiving port is configured to accept them. 


In order to prevent interoperability problems, sending 802.1Q frames is disabled by default for 
EtherNet/IP devices. The end user may elect to enable sending tagged frames when supported, 
via the QoS Object. The user is ultimately responsible for ensuring that both the sending and 
receiving devices support 802.1Q frames, and that network infrastructure is properly 
configured. 
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4-1 Introduction 


This chapter of the EtherNet/IP specification contains additions to the CIP object model that 
are EtherNet/IP specific. At this time, no such additions exist. 
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5-1 


Introduction 


In this standard, object modeling is used to represent the network visible behavior of devices. 
Devices are modeled as a collection of objects. Each class of objects is a collection of related 
services, attributes and behaviors. Services are the procedures that an object performs. 
Attributes are characteristics of objects represented by values, which can vary. An object’s 
behavior is an indication of how the object responds to particular events. 


This chapter of the specification contains the object descriptions specific to EtherNet/IP. The 
rest of the object descriptions can be found in the Volume 1, Chapter 5. With respect to the 
OSI reference model, CIP objects perform the Layer 7 Application functions. They also 
provide a mechanism to access station management counters via the network. 


Reserved Class Codes 


The rest of the class codes are defined in Volume 1 of the CIP Networks Library. 


~5-6— 
Edition 1.18 
SINGLE SUBSCRIPTION ONLY; SUBSCRIPTION TERMS AND CONDITIONS OUTLINED ON PAGE (iii) 


Volume 2: EtherNet/IP Adaptation of CIP, Chapter 5: Object Library 


5-3 


5-3.1 


Identity Object, Class Code: F5 Hex 


Identity Object 
Class Code: 01 Hex 


See Volume 1, Chapter 5 for the complete Identity Object specification. This section adds only 
to the Reset service definition. 


Reset Service 


The Reset service for the Identity Object, including which Reset Types are required or optional, 
is defined in Volume 1, Chapter 5. However, the details for Reset Type 2 (Return to Factory 
Defaults except Communication Parameters) are deferred to the relevant network volume. 
Therefore, this section describes the behavior of Reset Type 2 for EtherNet/IP 


The following table indicates the communication link attributes that shall be preserved when 
the device receives a Reset service with the Reset Type parameter value of 2. 


Table 5-3.1 Communication Link Attributes that shall be preserved 


Class Instance s Attribute 

Nine Attribute ID 

Configuration Control 3. 

TCP/IP Interface Object (F5 Hex) | Allexcept 0 | Interface Configuration 5 

Host Name 6 

Ethernet Link Object (F6 Hex) All except 0 | Interface Control 6 
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5-4.1 


5-4.2 


TCP/IP Object, Class Code: F5 Hex 


TCP/IP Interface Object 
Class Code: F5 Hex 


Scope 


The TCP/IP Interface Object provides the mechanism to configure a device’s TCP/IP network 
interface. Examples of configurable items include the device’s IP Address, Network Mask, and 
Gateway Address. 


The underlying physical communications interface associated with the TCP/IP Interface Object 
shall be any interface that supports the TCP/IP protocol. For example, a TCP/IP Interface 
Object may be associated with any of the following: an IEEE 802.3 interface, an ATM 
interface, a serial port running SLIP, a serial port running PPP, etc. The TCP/IP Interface 
Object provides an attribute that identifies the link-specific object for the associated physical 
communications interface. The link-specific object is generally expected to provide link- 
specific counters as well as any link-specific configuration attributes. 


Each device shall support exactly one instance of the TCP/IP Interface Object for each TCP/IP- 
capable communications interface on the module. 


Revision History 


Since the initial release of this object class definition changes have been made that require a 
revision update of this object class. The table below represents the revision history. 


Table 5-4.1 Revision History 


Revision Reason for Object Definition Update: 
1 Initial revision of this object definition 
va Added ACD Instance attributes 10 (SelectACD) and 11 (LastConflictDetected) 


Added Instance Attribute 12, EtherNet/IP QuickConnect 
Added bits 5 (Interface Configuration Pending) and 6 (AcdStatus) to Attribute 1, Status 


Added bits 6 (Interface Configuration Change Requires Reset) and 7 (AcdCapable) to 
Attribute 2, Configuration Capability 


Added bit 7 (AcdFault) to Attribute 1, Status 


4 Added Instance Attribute 13, Encapsulation Inactivity Timeout 
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5-4.3 Attributes 
5-4,3.1 Class Attributes 
Table 5-4.2 Class Attributes 
Attr Need in Description of _ 
ID ineratam Access Rule | NV Name Data Type ‘Attribute Semantics of values 
1 Required Get NV_ | Revision UINT Revision of this The value shall be 4. 
object 
2 Conditional ' Get NV_ | Max Instance UINT Maximum instance | The largest instance 
number of an object | number of a created 
currently created in | object at this class 
this class level of __| hierarchy level. 
the device. 
3 Conditional ! Get NV_ | Number of UINT Number of object The number of object 
Instances instances currently _ | instances at this class 
created at this class | hierarchy level 
level of the device. 
4 thru 7 These class attributes are optional and are described in Volume 1, Chapter 4. 


Table Footnotes 


1 Required if the number of instances is greater than 1. 


5-4.3.2 Instance Attributes 
Table 5-4.3 Instance Attributes 
Attr Need In Access NV Nene Data Description of Semantics of 
ID Implem Rule Type Attribute Values 
1 Required Get Vv Status DWORD | Interface status See section 5- 
43.2.1. 
2 Required Get NV Configuration DWORD | Interface capability | Bit map of 
Capability flags capability flags. See 
section 5-4,3.2.2. 
3 Required Get NV Configuration DWORD_ | Interface control Bit map of control 
Set is Control flags flags. See section 5- 
condi- 43.2.3 
tional ! 
4 Required Get NV Physical Link STRUCT | Path to physical link | See section 5- 
Object of: object 4.3.2.4 
Path size UINT Size of Path Number of 16 bit 
words in Path 
Path Padded Logical segments The path is 
EPATH | identifying the restricted to one 
physical link object | logical class 
segment and one 
logical instance 
segment. The 
maximum size is 12 
bytes. See Appendix 
C of Volume 1, 
Logical Segments. 
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Attr 


Need In 
Implem 


Access 
Rule 


NV 


Name 


Data 
Type 


Description of 
Attribute 


Semantics of 
Values 


Required 


Get 


Set is 
recom- 
mended 


NV when 
Configuration 
Method is 0. 
V when 
obtained via 
BOOTP or 
DHCP 


Interface 
Configuration 


STRUCT 
of: 


TCP/IP network 
interface 
configuration. 


See section 5-4.3.2.5 


IP Address 


UDINT 


The device’s IP 
address. 


Value of 0 indicates 
no IP address has 
been configured. 
Otherwise, the IP 
address shall be set to 
a valid Class A, B, or 
C address and shall 
not be set to the 
loopback address 
(127.0.0.1). 


Network Mask 


UDINT 


The device’s network 
mask 


Value of 0 indicates 
no network mask 
address has been 
configured. 


Gateway 
Address 


UDINT 


Default gateway 
address 


Value of 0 indicates 
no IP address has 
been configured. 
Otherwise, the IP 
address shall be set to 
a valid Class A, B, or 
C address and shall 
not be set to the 
loopback address 
(127.0.0.1). 


Name Server 


UDINT 


Primary name server 


Value of 0 indicates 
no name server 
address has been 
configured. 
Otherwise, the name 
server address shall be 
set to a valid Class A, 
B, or C address. 


Name Server 2 


UDINT 


Secondary name 
server 


Value of 0 indicates 
no secondary name 
server address has 
been configured. 
Otherwise, the name 
server address shall be 
set to a valid Class A, 
B, or C address. 


Domain Name 


STRING 


Default domain name 


ASCII characters. 
Maximum length is 
48 characters. Shall 
be padded to an even 
number of characters 
(pad not included in 
length). A length of 0 
shall indicate no 
Domain Name is 
configured. 
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Attr Need In Access NV Nantel Data Description of Semantics of 
ID Implem Rule Type Attribute Values 
6 Required Get NV Host Name STRING Host name ASCII characters. 
Set is Maximum length is 
Condi- 64 characters. Shall 
tional 2 be padded to an 
even number of 
characters (pad not 
included in length). 
A length of 0 shall 
indicate no Host 
Name is configured. 
See section 5- 
4.3.2.6. 
7 Conditional * Safety 6 octets See CIP Safety 
Network Specfication, 
Number Volume 5, Chapter 
3 
8 Conditional * | Get NV TTL Value USINT TTL value for Time-to-Live value 
Set is EtherNet/IP for IP multicast 
condi- multicast packets packets. Default 
tional ° value is 1. 
Minimum is 1; 
maximum is 255 
See Chapter 5- 
4.3.2.7. 
9 Conditional? | Get NV Mcast Config STRUCT | IP multicast address | See Chapter 5- 
Set is of: configuration 4.3.2.8. 
condi 
Bone Alloc Control USINT Multicast address See Chapter 5- 
allocation control 4.3.2.8 for details. 
word. Determines Determines whether 
how addresses are multicast addresses 
allocated. are generated via 
algorithm or are 
explicitly set. 
Reserved USINT Reserved for future | Shall be 0. 
use 
Num Mcast UINT Number of IP The number of IP 
multicast addresses | multicast addresses 
to allocate for allocated, starting at 
EtherNet/IP “Mcast Start Addr”. 
Maximum value is 
device specific, 
however shall not 
exceed the number 
of EtherNet/IP 
multicast 
connections 
supported by the 
device. 
Mcast Start UDINT Starting multicast IP multicast address 
Addr address from which (Class D). A block 
to begin allocation. of “Num Mcast” 
addresses is 
allocated starting 
with this address. 
-5-11- 
Edition 1.18 


SINGLE SUBSCRIPTION ONLY; SUBSCRIPTION TERMS AND CONDITIONS OUTLINED ON PAGE (iii) 


Volume 2: EtherNet/IP Adaptation of CIP, Chapter 5: Object Library 


TCP/IP Object, Class Code: F5 Hex 


Attr Need In Access NV Nani Data Description of Semantics of 
ID Implem Rule Type Attribute Values 
10 Conditional ° Set NV SelectAcd BOOL Activates the use of | Enable ACD (1, 
ACD default), Disable 
ACD (0). 
See section 5- 
4.3.2.9 
11 Conditional ® | Set NV LastConflictDe | STRUCT | Structure containing | ACD Diagnostic 
tected oft information related Parameters 
to the last conflict See section 5- 
detected 4.3.2.10 
AcdActivity USINT State of ACD ACD activity 
activity when last Default = 0 
conflict detected See section 5- 
4.3.2.10 
RemoteMAC Array of 6 | MAC address of MAC from Eth Pkt 
USINT remote node from Hdr. Default =O. 
the ARP PDU in See section 5- 
which a conflict was | 4.3.2.10 
detected 
ArpPdu ARRAY Copy of the raw ARP PDU 
of 28 ARP PDU in which | Default =0 
USINT a conflict was See section 5- 
detected. 4,3.2.10 
12 Optional Set NV EtherNet/IP BOOL Enable/Disable of 0 = Disable 
QuickConnect QuickConnect (default) 
feature 1 = Enable 
See Section 5- 
4,3.2.11. For 
information 
regarding 
QuickConnect, refer 
to Appendix E — 
EtherNet/IP 
QuickConnect 
13 Required Set NV Encapsulation UINT Number of seconds | 0 = Disable 
Inactivity of inactivity before 1-3600 = timeout in 
Timeout TCP connection is seconds 


closed 


Default = 120 
See section 5- 
4,3.2.12 


Table Footnotes 


wNe 


Dune 


If either TTL Value or Mcast Config is implemented, both must be implemented. 


Set is required unless the configuration method is selected exclusively via hardware setting. 
The set access is optional when the Interface Configuration atribute is not settable, 


If either TTL Value or Mcast Config is implemented as settable, both must be implemented as settable. 
REQUIRED if device implements ACD. 


This attribute is required for EtherNet/IP safety devices. Non-safety devices shall not implement this attribute. 


For information regarding QuickConnect, refer to Appendix E — EtherNet/IP QuickConnect. 


For information regarding ACD refer to Appendix F — Address Conflict Detection. 
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TCP/IP Object, Class Code: F5 Hex 
5-4,3.2.1 Status — Attribute 1 


The Status attribute is a bitmap that shall indicate the status of the TCP/IP network interface. 
Refer to the state diagram in section 5-4.5, Behavior, for a description of object states as they 
relate to the Status attribute. 


Table 5-4.4 Status Attribute 


Bit(s): Called: Definition 
0-3 Interface Indicates the status of | 0 = The Interface Configuration attribute has not been 
Configuration | the Interface configured. 
Status Configuration 1 = The Interface Configuration attribute contains 
attribute. configuration obtained from BOOTP, DHCP or non- 


volatile storage. 

2 = The IP address member of the Interface Configuration 
attribute contains configuration, obtained from hardware 
settings (e.g.: pushwheel, thumbwheel, etc.) 


3-15 = Reserved for future use. 


4 Mcast Pending | Indicates a pending configuration change in the TTL Value and/or Mcast Config 
attributes. This bit shall be set when either the TTL Value or Mcast Config 
attribute is set, and shall be cleared the next time the device starts. 


§ Interface Indicates a pending configuration change in the Interface Configuration attribute. 
Configuration | This bit shall be 1 (TRUE) when Interface Configuration attribute are set and the 
Pending device requires a reset in order for the configuration change to take effect (as 


indicated in the Configuration Capability attribute). 

The intent of the Interface Config Pending bit is to allow client software to detect 
that a device’s IP configuration has changed, but will not take effect until the 
device is reset. 


6 AcdStatus Indicates when an IP address conflict has been detected by ACD. 

This bit shall default to 0 (FALSE) on startup. If ACD is supported and enabled, 
then this bit shall be set to 1 (TRUE) any time an address conflict is detected as 
defined by the [ConflictDetected] transitions in Figure F-1.1 ACD Behavior. 


7 AcdFault Indicates when an IP address conflict has been detected by ACD or the defense 
failed, and that the current Interface Configuration cannot be used due to this 
conflict. This bit SHALL be | (TRUE) if an address conflict has been detected 
and this interface is currently in the Notification & FaultAction or 
AcquireNewIpv4Parameters ACD state as defined in Appendix F, and SHALL be 
0 (FALSE) otherwise. 

Notice that when this bit is set, then this CIP port will not be usable. However, 
for devices with multiple ports, this bit provides a way of determining if the port 
has an ACD fault and thus cannot be used. 


8-31 Reserved Reserved for future use and shall be set to zero. 


5-4,3.2.2 Configuration Capability — Attribute 2 


The Configuration Capability attribute is a bitmap that indicates the device’s support for 
optional network configuration capability. Devices are not required to support any one 
particular item, however must support at least one method of obtaining an initial IP address. 
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Table 5-4.5 Configuration Capability Attribute 


Bit(s): Called: Definition 


0 BOOTP Client | 1 (TRUE) shall indicate the device is capable of obtaining its network 
configuration via BOOTP. 


1 DNS Client 1 (TRUE) shall indicate the device is capable of resolving host names by 
querying a DNS server. 


2 DHCP Client | 1 (TRUE) shall indicate the device is capable of obtaining its network 
configuration via DHCP. 
3 DHCP-DNS Shall be 0, behavior to be defined in a future specification edition. 
Update 
4 Configuration | 1 (TRUE) shall indicate the Interface Configuration attribute is settable. 
Settable 
5 Hardware 1 (TRUE) shall indicate the IP Address member of the Interface Configuration 


Configurable _ | attribute can be obtained from hardware settings (e.g., pushwheel, thumbwheel, 
etc.). If this bit is FALSE the Status Instance Attribute (1), Interface 
Configuration Status field value shall never be 2 (The Interface Configuration 
attribute contains valid configuration, obtained from hardware settings) 


6 Interface 1 (TRUE) shall indicate that the device requires a restart in order for a change to 
Configuration | the Interface Configuration attribute to take effect. If this bit is FALSE a change 
Change in the Interface Configuration attribute will take effect immediately. 
Requires Reset 
7 AcdCapable (1) TRUE shall indicate that the device is ACD capable 
8-31 Reserved Reserved for future use and shall be set to zero. 


5-4,3.2.3 Configuration Control — Attribute 3 


5-4.3.2.3.1 | Configuration Control Structure 


The Configuration Control attribute is a bitmap used to control network configuration 
options. Table 5-4.6 shows the structure of the Configuration Control attribute: 


Table 5-4.6 Configuration Control Attribute 


Bit(s): Called: Definition 
0-3 Configuration | Determines how the | 0 = The device shall use statically-assigned IP configuration 
Method device shall obtain its | values. 
IP-related 1 = The device shall obtain its interface configuration values 
configuration via BOOTP. 
2 = The device shall obtain its interface configuration values 
via DHCP. 
3-15 = Reserved for future use. 
4 DNS Enable If 1 (TRUE), the device shall resolve host names by querying a DNS server. 
5-31 Reserved Reserved for future use and shall be set to zero. 
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5-4,3.2.3.2 Configuration Method 


The Configuration Method determines how a device shall obtain its IP-related configuration: 


e If the Configuration Method is 0, the device shall use statically-assigned IP configuration 
contained in the Interface Configuration attribute (or assigned via non-CIP methods, as 
noted below). 

e If the Configuration Method is 1, the device shall obtain its IP configuration via BOOTP. 
The BOOTP client behavior shall be as defined in the relevant RFCs (RFC 951, RFC 1542, 
RFC 2132) or their successors. 

e If the Configuration Method is 2, the device shall obtain its IP configuration via DHCP. The 
DHCP client behavior shall be as defined in the relevant RFCs (RFC 2131, RFC 2132) or 
their successors. 

e Devices that optionally provide hardware means (e.g., rotary switch) to configure IP 
addressing behavior shall set the Configuration Method to reflect the configuration set via 
hardware: 0 if a static IP address has been configured, | if BOOTP has been configured, 2 if 
DHCP has been configured. 


If a device has been configured to obtain its configuration via BOOTP or DHCP it shall 
continue sending requests until a response from the server is received. Devices that elect to use 
default IP configuration in the event of no response from the server shall continue issuing 
requests until a response is received, or until the Configuration Method is changed to static. 


Once the device receives a response from the server it shall stop sending the BOOTP/DHCP 
client requests (DHCP clients shall follow the lease renewal behavior per the RFC). It is 
recommended that devices implement the means to detect a link up and upon a link up 
detection restart the initial BOOTP or DHCP sequence. For multiport devices the restart of the 
initial BOOTP or DHCP sequence shall only be triggered if all external links have been down 
and when the first link up is detected. 


Setting the Configuration Method to 0 (static address) shall cause the Interface Configuration to 
be saved to NV storage. 


It is recommended that setting the Configuration Method to 1 (BOOTP) or 2 (DHCP) cause the 
device to start the BOOTP / DHCP client to obtain new IP address configuration. If the device 
requires a reset in order to start the BOOTP / DHCP client, it shall set the Interface Config 
Pending bit, and upon device reset start the BOOTP / DHCP client. 


5-4.3.2.3.3 DNS Enable 


For originator devices that support resolving target host names via DNS, the DNS Enable bit 
shall enable (1) and disable (0) the DNS client. 


5-4,3.2.4 Physical Link Object - Attribute 4 


This attribute identifies the object associated with the underlying physical communications 
interface (e.g., an 802.3 interface). There are two components to the attribute: a Path Size (in 
UINTs) and a Path. The Path shall contain a Logical Segment, type Class, and a Logical 
Segment, type Instance that identifies the physical link object. The maximum Path Size is 6 
(assuming a 32 bit logical segment for each of the class and instance). 
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The physical link object itself typically maintains link-specific counters as well as any link- 
specific configuration attributes. If the CIP port associated with the TCP/IP Interface Object 
has an Ethernet physical layer, this attribute shall point to an instance of the Ethernet Link 
Object (class code = OxF6). When there are multiple physical interfaces that correspond to the 
TCP/IP interface, this attribute shall either contain a Path Size of 0, or shall contain a path to 
the object representing an internal communications interface (often used in the case of an 
embedded switch). 


For example, the path could be as follows: 


Table 5-4.7 Example Path 


Path Meaning 


[20][F6][24][01] [20] = 8 bit class segment type; [F6] = Ethernet Link Object class; 
[24] = 8 bit instance segment type; [01] = instance 1. 


Interface Configuration - Attribute 5 


Interface Configuration Contents 


The Interface Configuration attribute contains the configuration parameters required for a 
device to operate as a TCP/IP node. The contents of the Interface Configuration attribute shall 
depend upon how the device has been configured to obtain its IP parameters: 


e If configured to use a static IP address (Configuration Method value is 0), the Interface 
Configuration values shall be those which have been statically assigned and stored in NV 
storage. 

e Ifconfigured to use BOOTP or DHCP (Configuration Method value is | or 2), the Interface 
Configuration values shall contain the configuration obtained from the BOOTP or DHCP 
server. The Interface Configuration attribute shall be 0 until the BOOTP/DHCP reply is 
received. 

e Some devices optionally provide additional, non-CIP mechanisms for setting IP-related 
configuration (e.g., a web server interface, rotary switch for configuring IP address, etc.). 
When such a mechanism is used, the Interface Configuration attribute shall reflect the IP 
configuration values in use. 


Table 5-4.8 Interface Configuration Attribute 


Name Meaning 
IP address The device’s IP address. 
Network mask The device’s network mask. The network mask is used when the IP network has 


been partitioned into subnets. The network mask is used to determine whether an IP 
address is located on another subnet. 


Gateway address The IP address of the device’s default gateway. When a destination IP address is on 
a different subnet, packets are forwarded to the default gateway for routing to the 
destination subnet. 


Name server The IP address of the primary name server. The name server is used to resolve host 
names. For example, that might be contained in a CIP connection path. 


Name server 2 The IP address of the secondary name server. The secondary name server is used 
when the primary name server is not available, or is unable to resolve a host name. 


Domain name The default domain name. The default domain name is used when resolving host 
names that are not fully qualified. For example, if the default domain name is 
“odva.org”, and the device needs to resolve a host name of “plc”, then the device will 
attempt to resolve the host name as “plc.odva.org”. 
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For additional information on IP addressing, subnetworks, gateways, etc. refer to Comer, 
Douglas E.; Internetworking with TCP/IP, Volume 1: Protocols and Architecture; Englewood 
Cliffs, NJ; Prentice-Hall, 1990. 


Set Attributes Behavior 


In order to prevent incomplete or incompatible configuration, the parameters making up the 
Interface Configuration attribute cannot be set individually. To modify the Interface 
Configuration attribute, client software should first Get the Interface Configuration attribute, 
change the desired parameters, and then Set the attribute. 


An attempt to set any of the parameters of the Interface Configuration attribute to invalid 
values (see Semantics of Values in Table 5-3.2) shall result in an error response with status 
code 0x09 ‘Invalid Attribute Value’ to be returned. In this scenario, all of the parameters of the 
Interface Configuration attribute retain the values that existed prior to the invocation of the set 
service. 


If the device has an active I/O connection, it is recommended that the device rejects the set 
attributes request by returning an error response with status code 0x10 “Device State Conflict’. 


When the value of the Configuration Method (Configuration Control attribute) is 0, the set 
attribute service shall store the new Interface Configuration values in non-volatile memory. If 
the device requires reset in order for new parameters to take effect (Configuration Capability 
bit 6 set), the device shall set the Interface Configuration Pending bit (Status attribute bit 5). 


After storing the new values the device shall send a response using its current IP address (i.e., 
the IP address to which the set attributes request was sent). 


Tf the device does not require reset (Configuration Capability bit 6 clear) in order for new IP 
configuration to take effect, after responding to the set service the device shall initiate 
application of the new IP parameters. While implementation-dependent, this activity is 
generally initiated by the TCP/IP Interface Object set service and then completed 
asynchronously by the TCP/IP stack. 


In order to achieve consistency of device configuration behavior, it is recommended that 
devices support setting the Interface Configuration attribute, and support application of new 
attribute values without requiring device reset. If a device does not support setting the Interface 
Configuration attribute, the device shall return an error response with status code 0xOE 
“Attribute Not Settable’. 


Application of New Configuration Parameters 


If the device does not require reset (Configuration Capability bit 6 clear), after responding to 
the set service the device shall initiate application of the new IP parameters. When applying 
new IP configuration, the device shall maintain the consistency of the IP configuration context 
in which it operates. For example, the device shall not mix old and new IP address / network 
mask / gateway address values, and must not use the new IP configuration on CIP connections 
established with the previous IP address. 
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When a TCP/IP stack is configured to use a particular set of IP parameters, a context around 
these IP parameters is built. This context includes relationships to the TCP/IP stack, the CIP 
communications environment, and the control application among other entities. To allow a 
different set of IP parameters to be used a new IP context shall be built. The device shall 
properly manage its IP context and maintain its consistency. For example a new IP Address 
shall not be used with old Network Mask or Gateway Address; don’t use old IP address for CIP 
or other communication once the new one is applied. 


Host Name - Attribute 6 


The Host Name attribute contains the device’s host name, which can be used for informational 
purposes. The set access is optional when the Interface Configuration attribute is not settable. 


TTL Value - Attribute 8 


TTL Value is value the device shall use for the IP header Time-to-Live field when sending 
EtherNet/IP packets via IP multicast. By default, TTL Value shall be 1. The maximum value 
for TTL is 255. Note that unicast packets shall use the TTL as configured for the TCP/IP stack, 
and not the TTL Value configured in this attribute. 


When set, the TTL Value attribute shall be saved in non-volatile memory. If a device does not 
support applying the TTL Value immediately, the Mcast Pending bit in the Interface Status 
attribute shall be set, indicating that there is pending configuration. For devices that support 
applying the TTL Value immediately, if there are existing multicast connections, an Object 
State Conflict error (OxC) shall be returned and the Mcast Pending bit shall not be set. When a 
new TTL Value is pending, Get_Attribute_Single or Get_Attributes_AII requests shall return 
the pending value. The Mcast Pending bit shall be cleared the next time the device starts. 


Users should exercise caution when setting the TTL Value greater than 1, to prevent unwanted 


multicast traffic from propagating through the network. Chapter 3 includes a discussion on user 
considerations when using multicast. 


Mcast Config - Attribute 9 


The Meast Config attribute contains the configuration of the device’s IP multicast addresses to 
be used for EtherNet/IP multicast packets. There are three elements to the Mcast Config 
structure: Alloc Control, Num Mcast, and Mcast Start Addr. 


Alloc Control determines how the device shall allocate IP multicast addresses (e.g., whether 
by algorithm, whether they are explicitly set, etc.) Table 5-4.9 shows the details for Alloc 
Control. 


Table 5-4.9 Alloc Control 


Value Definition 


1) Multicast addresses shall be generated using the default allocation algorithm specified in 
Chapter 3. When this value is specified on a set-attribute or set-attributes-all, the values 
of Num Mcast and Mcast Start Addr in the set-attribute request shall be 0. 


1 Multicast addresses shall be allocated according to the values specified in Num Mcast and 
Mcast Start Addr. 


2 Reserved 


Num Meast is the number of IP multicast addresses allocated. The maximum number of 
multicast addresses is device specific, but shall not exceed the number of EtherNet/IP multicast 
connections supported by the device. 
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Mceast Start Addr is the starting multicast address from which Num Mcast addresses are 
allocated. 


When set, the Mcast Config attribute shall be saved in non-volatile memory. If a device does 
not support applying the MCast Config attribute immediately, the Mcast Pending bit in the 
Interface Status attribute shall be set, indicating that there is pending configuration. For devices 
that support applying the Mcast Config attribute immediately, if there are existing multicast 
connections an Object State Conflict error (OxC) shall be returned and the MCast Pending bit 
shall not be set. When a new Mcast Config value is pending, Get_Attribute_Single or 
Get_Attributes_All requests shall return the pending value. The Mcast Pending bit shall be 
cleared the next time the device starts. 


When the multicast addresses are generated using the default algorithm, Num Mcast and Mcast 
Start Addr shall report the values generated by the algorithm. 
SelectAcd — Attribute 10 
SelectAcd is an attribute used to Enable/Disable ACD. 
If SelectAcd is 0 then ACD is disabled. If SelectAcd =1 then ACD is enabled. 
The default value of SelectAcd shall be 1 indicating that ACD is enabled. 
When the value of SelectAcd is changed by a Set_Attribute service, the new value of 
SelectAcd shall not be applied until the device executes a restart. 
LastConflictDetected — Attribute 11 


The LastConflictDetected attribute is a diagnostic attribute presenting information about the 
ACD state when the last IP Address conflict was detected. This attribute shall be updated by 
the device whenever an incoming ARP packet is received that represents a conflict with the 
device’s IP address as described in IETF RFC 5227. 


To reset this attribute the Set_Attribute_Single service is invoked with an attribute value of all 
0. Values other than 0 shall result in an error response (status code 0x09, Invalid Attribute 
Value). 


AcdActivity — The ACD contains the state of the ACD algorithm when the last IP address 
conflict was detected. The ACD activities are defined in the following table. 


Table 5-4.10 AcdActivity 


Value AcdMode Description 
0 NoConflictDetected | No conflict has been detected since this attribute was last cleared. 
(Default) 
1 Probelpv4 Address Last conflict detected during Probelpv4Address state. 
2 OngoingDetection Last conflict detected during OngoingDetection state or subsequent 
DefendWithPolicyB state. 
3) SemiActiveProbe Last conflict detected during SemiActiveProbe state or subsequent 


DefendWithPolicyB state. 


RemoteMac — The IEEE 802.3 source MAC address from the header of the received Ethernet 
packet which was sent by a device reporting a conflict. 


ArpPdu — The ARP Response PDU in binary format. 
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The ArpPdu shall be a copy of the ARP message that caused the address conflict. It SHALL be 


araw copy of the ARP message as it appears on the Ethernet network, i.e.: ArpPdu[1] contains 
the first byte of the ArpPdu received. 
Table 5-4.11 ArpPdu - The ARP Response PDU in binary format 
Field Size Field Description Field Value 
[bytes] 
2 Hardware Address Type 1 for Ethernet H/W 
2 Protocol Address Type 0x800 for IP 
1 HADDR LEN 6 for Ethernet h/w 
1 PADDR LEN 4 for IP 
2 OPERATION 1 for Req or 2 for Rsp 
6 SENDER HADDR Sender’s h/w addr 
4 SENDER PADDR Sender’s proto addr 
6 TARGET HADDR Target’s h/w addr 
4 TARGET PADDR Target’s proto addr 
EtherNet/IP QuickConnect™ — Attribute 12 
The EtherNet/IP QuickConnect attribute shall enable (1) or disable (0) the QuickConnect 


feature. The default value of the attribute shall be 0. 


For information regarding QuickConnect, refer to Appendix E — "EtherNet/IP QuickConnect". 


Encapsulation Inactivity Timeout — Attribute 13 


The Encapsulation Inactivity Timeout attribute is used to enable TCP socket cleanup (closing) 
when the defined number of seconds have elapsed with no Encapsulation activity. 
Encapsulation activity is defined in section 2-5.5.2, TCP Connection Management for 
EtherNet/IP. 


When set, the Encapsulation Inactivity Timeout attribute shall be saved in non-volatile memory 
and applied to all subsequently-opened connections. Devices should also, if feasible, apply 
Encapsulation Inactivity Timeout changes to all currently-opened connections. 


Common Services 
All Services 
The TCP/IP Interface Object shall provide the following common services. 


Table 5-4.12 Common Services 


Service Need in Implementation 
Code Class Instance Service name Description of Service 
Ox01 Optional Optional Get_Attributes_All Returns a predefined listing of this objects attributes (See 
the Get_Attributes_All response definition in section 5- 
4.4.2) 
0x02 na Optional Set_Attributes_All Modifies all settable attributes. 
Ox0E Required Required Get_Attribute_Single Returns the contents of the specified attribute. 
0x10 na Required Set_Attribute_Single Modifies a single attribute. 
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Get_Attributes_All Response 


At the class level, the Get_Attributes_All response shall contain the class attributes in 
numerical order, up to the last implemented attribute. Any unimplemented attributes in the 
response shall use the default attribute values. 


For instance attributes, attributes shall be returned in numerical order up to the last 
implemented attribute. The Get_Attributes_All reply shall be as follows: 
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Attribute ID Data Type Attribute Name Default Value (if not 
implemented) 
1 DWORD Status 
2 DWORD Configuration Capability 
3 DWORD Configuration Control 
STRUCT of: Physical Link Object 
4 UINT Path Size 
Padded EPATH Path 
STRUCT of: Interface Configuration 
UDINT IP Address 
UDINT Network Mask 
F UDINT Gateway Address 
UDINT Name Server 
UDINT Name Server 2 
STRING Domain Name 
USINT Pad | 
STRING Host Name 
. USINT Pad? 

7 6 octets Safety Network Number 0 
8 USINT TTL Value 1 
STRUCT of: Mcast Config 

USINT Alloc control 0 

9 USINT Reserved 0 

UINT Num Meast 0 

UDINT Meast Start Addr 0 

10 BOOL SelectAcd 0 

STRUCT of: LastConflictDetected 

USINT AcdActivity 0 

te ARRAY of 6 USINTs | RemoteMAC 0 

ARRAY of 28 USINTs | ArpPdu 0 

12 BOOL EtherNet/IP QuickConnect |9 
B UINT Expo Inactivity 


Table Footnotes 


1 Pad byte only included if the Domain Name length is odd 
2. Pad byte only included if the Host Name length is odd 


Important: Insert the default value for all unsupported attributes that are included in the 
response. 
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The lengths of the Physical Link Object path, Domain Name, and Host Name are not known 
before issuing the Get_Attributes_All service request. Implementers shall be prepared to 
accept a response containing the maximum sizes of the Physical Link Object path (6 UINTs), 


the Domain Name (48 USINTs), and Host Name (64 USINTs). 


5-4.4.3 Set_Attributes_All Request 
The instance Set_Attributes_All request contains the Configuration Control attribute, followed 
by the Interface Configuration attribute. 

5-4.5 Behavior 


The behavior of the TCP/IP Interface Object shall be as illustrated in the Diagram below. Note 
that the act of obtaining an initial executable image via BOOTP/TFTP shall not be considered 
within the scope of the TCP/IP Interface Object behavior. Devices are free to implement such 
behavior, however it shall be considered to have occurred in the “Non-Existent” state. 


Figure 5-4.1 Diagram Showing the Behavior of the TCP/IP Object 
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Ethernet Link Object 
Class Code: F6 Hex 
Scope 


The Ethernet Link Object maintains link-specific counters and status information for an IEEE 
802.3 communications interface. Each device shall support exactly one instance of the Ethernet 
Link Object for each IEEE 802.3 communications interface on the module. Devices may use an 
Ethernet Link Object instance for an internally accessible interface, such as an internal port for 
an embedded switch, Refer to Chapter 6 (Device Profiles) for additional information on multi- 
port EtherNet/IP devices. 


Revision History 


Since the initial release of this object class definition changes have been made that require a 
revision update of this object class. The table below represents the revision history. 


Table 5-5.1 Revision History 


Revision Reason for Object Definition Update 


Initial revision of this object definition 
Add Instance Attribute 6, Interface Control 
Add new instance attributes 7-10 providing support for multiple port Ethernet devices 


Add | Gbps Forced Speed Setting behavior; add Instance Attribute 11, Interface Capability; 
add Instance Attributes 12 and 13 (HC counters) 


In| wl rm] = 


Attributes 

Class Attributes 

The Ethernet Link Object shall support the following class attributes. 
Table 5-5.2 Class Attributes 


Attr 


Need in Access | NV Name Jute Description of Attribute Semantics of Values 
Implem Rule Type 


Required Get NV | Revision UINT | Revision of this object The current value shall be 4 


Conditional ‘| Get NV | Max Instance | UINT | Maximum instance number | The largest instance number of a 
of an object currently created object at this class 
created in this class level of | hierarchy level 

the device 


onditional et umber of umber of object instances e number of object instances 
Conditional | | G NV _ | Number of UINT | Number of object i Th ber of object i: 
Instances currently created at this at this class hierarchy level 
class level of the device 


4 thru 7 


These class attributes are optional and are described in Volume 1, Chapter 4. 


Table Footnotes 


1 Required if the number of instances is greater than 1. 
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5-5.3.2 Instance Attributes 
The Ethernet Link Object shall support the following instance attributes. 
Table 5-5.3 Instance Attributes 
Attr Need in | Access | NV Fae; 4 . 
ID hoa Rule Name Data Type | Description of Attribute | Semantics of Values 
1 Required Get V_ | Interface Speed UDINT Interface speed currently | Speed in Mbps (e.g., 0, 
in use 10, 100, 1000, etc.) 
See section 5-5.3.2.1 
2 Required Get | V_ | Interface Flags DWORD __ | Interface status flags Bit map of interface 
flags. See section 
5-5.3.2.2 
3 Required Get | NV | Physical Address | ARRAY of | MAC layer address See section 
6 USINTs 5. 3. 
4 | Conditional! | Get | V_ | Interface Counters | STRUCT See section 
of: 5-53.24 
In Octets UDINT Octets received on the 
interface 
In Ucast Packets UDINT Unicast packets received 
on the interface 
In NUcast Packets | UDINT Non-unicast packets 
received on the interface 
In Discards UDINT Inbound packets received 
on the interface but 
discarded 
In Errors UDINT Inbound packets that 
contain errors (does not 
include In Discards) 
In Unknown UDINT Inbound packets with 
Protos unknown protocol 
Out Octets UDINT Octets sent on the 
interface 
Out Ucast Packets | UDINT Unicast packets sent on 
the interface 
Out NUcast UDINT Non-unicast packets sent 
Packets on the interface 
Out Discards UDINT Outbound packets 
discarded 
Out Errors UDINT Outbound packets that 
contain errors 
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Attr | Needin | Access] NV | nae | eet Tea ; 
ID Loy am Rule Name Data Type | Description of Attribute | Semantics of Values 
5 | Conditional? | Get V_ | Media Counters STRUCT | Media-specific counters See section 
of: 5-53.25 
Alignment Errors | UDINT Frames received that are 
not an integral number of 
octets in length 
FCS Errors UDINT Frames received that do 
not pass the FCS check 
Single Collisions | UDINT Successfully transmitted 
frames which experienced 
exactly one collision 
Multiple UDINT Successfully transmitted 
Collisions frames which experienced 
more than one collision 
SQE Test UDINT Number of times SQE test 
Errors error message is generated 
Deferred UDINT Frames for which first 
Transmissions transmission attempt is 
delayed because the 
medium is busy 
Late Collisions UDINT Number of times a 
collision is detected later 
than 512 bit-times into the 
transmission of a packet 
Excessive UDINT Frames for which 
Collisions transmission fails due to 
excessive collisions 
MAC Transmit UDINT Frames for which 
Errors transmission fails due to 
an internal MAC sublayer 
transmit error 
Carrier Sense UDINT Times that the carrier 
Errors sense condition was lost or 
never asserted when 
attempting to transmit a 
frame 
Frame Too Long | UDINT Frames received that 
exceed the maximum 
permitted frame size 
MAC Receive UDINT Frames for which 
Errors reception on an interface 
fails due to an internal 
MAC sublayer receive 
error 
6 | Optional Set NV | Interface Control |STRUCT | Configuration for physical | See section 
of: interface 5-5.3.2.6 
Control Bits WORD Interface Control Bits 
Forced Interface UINT Speed at which the Speed in Mbps (10, 100, 
Speed interface shall be forced to | 1000, etc.) 
operate 
7 | Optional Get NV | Interface Type USINT Type of interface: twisted | See section 
pair, fiber, internal, etc 5-5.3.2.7 
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Attr | Needin | Access} NV aes e . 
ID Taman Rule Name Data Type | Description of Attribute | Semantics of Values 
8 | Optional Get V_ | Interface State USINT Current state of the See section 
interface: operational, 5-5.3.2.8 
disabled, ete 
9 | Optional Set NV | Admin State USINT Administrative state: See section 
enable, disable 5-5.3.2.9 
10 | Conditional’ | Get NV | Interface Label SHORT_ Human readable See section 5-5.3.2.10 
STRING identification 
11 | Required Get NV | Interface STRUCT | Indication of capabilities | See section 5-5.3.2.11 
Capability oft of the interface 
Capability Bits DWORD _ | Interface capabilities. Bit map 
other than speed/duplex 
Speed/Duplex STRUCT | Indicates speed/duplex 
Options of: pairs supported in the 
Interface Control attribute 
USINT Speed/Duplex Array Number of elements 
Count 
ARRAY of | Speed/Duplex Array 
STRUCT 
of: 
UINT Interface Speed Semantics are the same 
as the Forced Interface 
Speed in the Interface 
Control attribute: speed 
in Mbps. 
USINT Interface Duplex Mode O=half duplex 
1=full duplex 
2-255=Reserved 
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Attr | Needin | Access} NV are e . 
ID henien Rule Name Data Type | Description of Attribute | Semantics of Values 
12 | Conditional * | Get V._ | HC Interface STRUCT | High Capacity Interface See section 5-5.3.2.12 
Counters of: Counters 
HCInOctets ULINT The total number of octets 
received on the interface. 
This counter is a 64-bit 
vel of In Oct 
HCInUcastPkts ULINT Unicast packets received 
on the interface. This 
counter is a 64-bit version 
of In Ucast Packets. 
HCInMulticastPkt_ | ULINT Multicast packets received 
s on the interface. 
HCInBroadcastPkt | ULINT Broadcast packets 
s received on the interface. 
HCOutOctets ULINT Octets sent on the 
interface. This counter is a 
64-bit version of Out 
Octets. 
HCOutUcastPkts | ULINT Unicast packets sent on 
the interface. This counter 
isa it ver of Out 
Ucast Packets. 
HCOutMulticastP | ULINT Multicast packets sent on 
kts the interface. 
HCOutBroadcastP | ULINT Broadcast packets sent on 
kts the interface 
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Attr Need in 


Implem 


Access 
Rule 


NV 


Name 


Data Type 


Description of Attribute 


Semantics of Values 


Conditional * 


Get 


¥ 


HC Media 


STRUCT 


High Capacity Media 


See section 5-5.3.2.12 


Counters 


of: 


Counters 


HCStatsAlignment 


ULINT 


Frames received that are 


Errors 


not an integral number of 
octets in length and do not 
pass the FCS check. This 
counter is a 64-bit version 


of Alignment Errors. 


HCStatsFCSErrors 


ULINT 


Frames received that are 


an integral number of 

octets in length but do not 
pass the FCS check. This 
counter is a 64-bit version 
of FCS Errors. 


HCStatsInternalM 


ULINT 


Frames for which 


acTransmitErrors 


transmission fails due to 


an internal MAC sublayer 
transmit error. This 


of MAC Transmit Errors. 


HCStatsFrameToo 


ULINT 


Frames received that 


Longs 


exceed the maximum 
permitted frame size. This 
counter is a 64-bit version 


of Frame Too Long 
Errors. 


HCStatsInternalM 


ULINT 


Frames for which 


acReceiveErrors 


reception on an interface 
fails due to an internal 


MAC sublayer receive 
error. This counter is a 
64-bit version of MAC 
Receive Error 


HCStatsSymbolEr 


ULINT 


Number of times there was 


rors 


an invalid data symbol on 
the media when a valid 


carrier was present. 


Table Footnotes 


1. The Interface Counters attribute is required if the HC Interface Counters attribute or Media Counters attribute is 
implemented, otherwise highly recommended. 
2. Required if the devices supports DLR or if the HC Media Counters attribute is implemented, otherwise highly 


recommended, 


3.__ Required if number of instances is greater than 1. 
4. Required for interfaces that support 1 Gbps speeds and higher, otherwise highly recommended. 


5-5.3.2.1 


Interface Speed — Attribute 1 


The Interface Speed attribute shall indicate the speed at which the interface is currently running 
(e.g., 10 Mbps, 100 Mbps, | Gbps, etc.) A value of 0 shall be used to indicate that the speed of 


the interface is indeterminate. The scale of the attribute is in Mbps, so if the interface is running 


at 100 Mbps then the value of Interface Speed attribute shall be 100. The Interface Speed is 
intended to represent the media bandwidth; the attribute shall not be doubled if the interface is 
running in full-duplex mode. 
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5-5,3.2.2 Interface Flags — Attribute 2 
The Interface Flags attribute contains status and configuration information about the physical 
interface and shall be as follows: 
Table 5-5.4 Interface Flags 
Bit(s): Called: Definition 

0 Link Status Indicates whether or not the IEEE 802.3 communications interface is connected to an active 
network. 0 indicates an inactive link; | indicates an active link. The determination of link 
status is implementation specific. In some cases devices can tell whether the link is active 
via hardware/driver support. In other cases, the device may only be able to tell whether the 
link is active by the presence of incoming packets. 

1 Half/Full Duplex Indicates the duplex mode currently in use. 0 indicates the interface is running half duplex; 
1 indicates full duplex. Note that if the Link Status flag is 0, then the value of the Half/Full 
Duplex flag is indeterminate. 

2-4 Negotiation Status Indicates the status of link auto-negotiation 
0 = Auto-negotiation in progress. 
1 = Auto-negotiation and speed detection failed. Using default values for speed and duplex. 
Default values are product-dependent; recommended defaults are 1OMbps and half duplex. 
2 = Auto negotiation failed but detected speed. Duplex was defaulted. Default value is 
product-dependent; recommended default is half duplex. 
3 = Successfully negotiated speed and duplex. 
4 = Auto-negotiation not attempted. Forced speed and duplex. 
5 Manual Setting The Manual Setting Requires Reset bit is the same as the identically-named bit in the 
Requires Reset Interface Capability attribute (#11). This bit shall be duplicated in both attributes in order 
to retain backwards compatibility with previous object revisions. 

6 Local Hardware Fault | 0 indicates the interface detects no local hardware fault; 1 indicates a local hardware fault is 
detected. The meaning of this is product-specific. Examples are an AUI/MII interface 
detects no transceiver attached or a radio modem detects no antennae attached. In contrast 
to the soft, possible self-correcting nature of the Link Status being inactive, this is assumed 
a hard-fault requiring user intervention. 

7-31 | Reserved Shall be set to zero 

5-5.3.2.3 Physical Address — Attribute 3 
The Physical Address attribute contains the interface’s MAC layer address. The Physical 
Address is an array of octets. The recommended display format is "XX-XX-XX-XX-XX-XX", 
starting with the first octet. Note that the Physical Address is not a settable attribute. The 
Ethernet address shall be assigned by the manufacturer, and shall be unique per IEEE 802.3 
requirements. Devices with multiple ports but a single MAC interface (e.g., a device with a 
embedded switch technology) may use the same value for this attribute in each instance of the 
Ethernet Link Object. The general requirement is that the value of this attribute shall be the 
MAC address used for packets to and from the device’s own MAC interface over this physical 
port. 

5-5.3.2.4 Interface Counters — Attribute 4 


The Interface Counters attribute contains counters relevant to the receipt of packets on the 
interface. These counters shall be as defined in RFC 1213 “MIB-II Management Information 
Base”. The Interface Counters are a conditional attribute; they shall be implemented if the 
Media Counters attribute is implemented. Multi-port devices with a single MAC interface (e.g., 
device with an embedded switch) shall maintain counter values in one of three ways: 
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5-5.3.2.6.1 
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1 In each instance, count the MAC frames sent/received by the device itself over the port 
represented by that instance (i.e., ea ch physical interface counts the MAC frames 
sent/received over that interface). This is the preferred solution. 


is) 


Use counter values of 0 for those instances that correspond to the external switch ports; 
count MAC frames in the instance that corresponds to the internal device interface 


3. Use the same counter values for all instances, counting MAC frames sent/received by the 
device itself 
Media Counters - Attribute 5 


The Media Counters attribute contains counters specific to Ethernet media. These counters 
shall be as defined by RFC 1643, “Definitions of Managed Objects for Ethernet-Like Interface 
Types”. If this attribute is implemented the Interface Counters shall also be implemented. 
Instances that refer to internal interfaces may set the values of the Interface Counters to 0. 


Note: some underlying hardware or system implementations may not provide all of the Media 
Counters. In the case of fiber media, some of the counters do not apply (e.g., collision 
counters). Devices shall use values of 0 for counters that are not implemented. 

Interface Control — Attribute 6 
The Interface Control attribute is a structure consisting of Control Bits and Forced Interface 
Speed and shall be as follows: 

Control Bits 
Table 5-5.5 Control Bits 


Bit(s): Called: Definition 

0 Auto-negotiate | 0 indicates 802.3 link auto-negotiation is disabled. 1 indicates auto-negotiation is enabled. If 
auto-negotiation is disabled, then the device shall use the settings indicated by the Forced 
Duplex Mode and Forced Interface Speed bits. 

1 Forced Duplex _| If the Auto-negotiate bit is 0, the Forced Duplex Mode bit indicates whether the interface shall 

Mode operate in full or half duplex mode. 0 indicates the interface duplex should be half duplex. 1 
indicates the interface duplex should be full duplex. Interfaces not supporting the requested 
duplex shall return status code 0x09 (Invalid Attribute Value). If auto-negotiation is enabled, 
attempting to set the Forced Duplex Mode bit shall result in status code 0xOC (Object State 
Conflict). 
2-15 Reserved Shall be set to zero 
5-5,.3.2.6.2 Forced Interface Speed 


= 


the Auto-negotiate bit is 0, the Forced Interface Speed bits indicate the speed at which the 
interface shall operate. Speed is specified in megabits per second (e.g., for 10 Mbps Ethernet, 
he Interface Speed shall be 10). 


For Gigabit Ethernet speeds (1 Gbps and above), the standard auto negotiation procedure is 
mandatory per the IEEE 802.3 specification. Setting the Auto-negotiate bit to 0 and Forced 
Interface Speed to 1000 or above shall cause the interface to advertise_only the specified speed 
and only the specified Forced Duplex Mode during link negotiation (per the IEEE 802.3 


standard). 
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Interfaces not supporting the requested speed shall return status code 0x09 (Invalid Attribute 
Value). If auto-negotiation is enabled, attempting to set the Forced Interface Speed shall result 
in status code Ox0C (Object State Conflict). 


5-5.3.2.7 Interface Type — Attribute 7 
The Interface Type attribute shall indicate the type of the physical interface. Table 5-5.6 shows 
the Interface Type values. This attribute shall be stored in non-volatile memory. 
Table 5-5.6 Interface Type 
Value Type of interface 
0 Unknown interface type. 
1 The interface is internal to the device, for example, in the case of an embedded switch. 
2 Twisted-pair (e.g., 10Base-T, 100Base-TX, 1000Base-T, etc.) 
3 Optical fiber (e.g., 100Base-FX) 
4-255 | Reserved. 
5-5.3.2.8 Interface State — Attribute 8 
The Interface State attribute shall indicate the current operational state of the interface. Table 5- 
5.7 shows the Interface State values. This attribute shall be stored in volatile memory. 
Table 5-5.7 Interface State 
Value Interface State 
0 Unknown interface state 
1 The interface is enabled and is ready to send and receive data 
2 The interface is disabled 
3 The interface is testing 
4-255 | Reserved. 
5-5.3.2.9 Admin State - Attribute 9 


The Admin State attribute shall allow administrative setting of the interface state. Table 5-5.8 
shows the Admin State values. This attribute shall be stored in non-volatile memory. 


Table 5-5.8 Admin State 


Value 


Admin State 


0 


Reserved 


Enable the interface 


2 


Disable the interface. 


3-255 


Reserved. 


Devices whose only communications port is an EtherNet/IP port with a single Ethernet Link 
instance shall return general status code 0x09 - Invalid Attribute Value if a request to disable its 
interface is received. Devices with multiple ports (any combination of multiple Ethernet Link 
instances and/or other communications ports) shall return general status code 0x10 - Device 
State Conflict if performing a disable request for an interface would result in all of the device’s 


communication ports becoming disabled. 
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Interface Label — Attribute 10 


The Interface Label attribute shall be a text string that describes the interface. The content of 
the string is vendor specific. For internal interfaces the text string should include “internal” 
somewhere in the string. The maximum number of characters in this string is 64. This attribute 
shall be stored in non-volatile memory. 


5- 11 Interface Capability — Attribute 11 


The Interface Capability attribute shall indicate the set of capabilities for the interface. The 
attribute is a structure with two main elements: Capability Bits and Speed/Duplex Options. 


Capability Bits contains an array of bits that indicate whether the interface supports capabilities 
such as auto-negotiation and auto-MDIX. Table 5-5.9 specifies the capability bits. 


Table 5-5.9 Capability Bits 


Bit(s): Called: Definition 
0 Manual Setting Indicates whether or not the device requires a reset to apply changes made to the Interface 
Requires Reset Control attribute (#6). 
0 = Indicates that the device automatically applies changes made to the Interface Control 
attribute (#6) and, therefore, does not require a reset in order for changes to take effect. 
This is the value this bit shall have when the Interface Control attribute (#6) is not 
implemented. 
1 = Indicates that the device does not automatically apply changes made to the Interface 
Control attribute (#6) and, therefore, will require a reset in order for changes to take effect. 
Note: this bit shall also be replicated in the Interface Flags attribute (#2) in order to retain 
backwards compatibility with previous object revisions. 
‘L Auto-negotiate 0 = Indicates that the interface does not support link auto-negotiation 
1 = Indicates that the interface supports link auto-negotiation 
2 Auto-MDIX 0 = Indicates that the interface does not support auto MDIX operation 
1 = Indicates that the interface supports auto MDIX operation 
A: Manual 0 = Indicates that the interface does not support manual setting of speed/duplex. The 
Speed/Duplex Interface Control attribute (#6) shall not be supported. 
4-31 | Reserved Shall be set to 0 
The Speed/Duplex Options element holds an array that indicates the speed/duplex pairs that 
may be set via the Interface Control instance attribute (#6). One speed/duplex pair (e.g., 10 
Mbps-half duplex, 100 Mbps-full duplex, etc.) shall be returned for each combination 
supported by the interface. 
5-5.3.2.12 High Capacity (HC) Counters — Attributes 12 and 13 


The two HC counter attributes (attributes 12 and 13) contain 64-bit versions of the equivalent 
32-bit counters (attributes 4 and 5). The 64-bit counters have the same basic semantics as their 
32-bit counterparts, extended to 64 bits. 


The HC Interface Counters attribute contains 64-bit versions of the Interface Counters. 
Counters in this attribute are in conformance with the Interfaces Group MIB defined by REC 
2863. Note that in the 32-bit Interface Counters, the counters for multicast and broadcast 
packets are combined as non-unicast packets. 
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The HC Media Counters attribute contains 64-bit versions of the Media Counters. Counters in 
this attribute are in conformance with the Ethernet-Like MIB defined by RFC 3635. 


For interfaces that have the capability to operate at 1 Gbps or faster, 64-bit counters SHALL be 
implemented and report accurate values when the interface is operating at any of its supported 
speeds. When 64-bit counters are in use, the 32-bit counters SHALL still be available and shall 
report the low 32 bits of the associated 64-bit counter. 


Common Services 
All Services 


The Ethernet Link Object shall provide the following common services. 


Table 5-5.10 Common Services 


Service | Need in Implementation 


Code Class Instance Service Name Description of Service 


0x01 Optional Optional Get_Attributes_All Returns a predefined listing of this objects attributes 
(See the Get_Attributes_All response definition in 
section 5-5.4.2) 


Ox0E Conditional Required | Get_Attribute_Single | Returns the contents of the specified attribute. 


0x10 wa Conditional | Set_Attribute_Single | Modifies a single attribute. 


The Get_Attribute_Single service shall be implemented for the class if any class attribute is 
implemented. 


The Set_Attribute_Single service shall be implemented if the Interface Control or Admin State 
attributes are implemented. 


Get_Attributes_All Response 


At the class level, the Get_Attributes_All response shall contain the class attributes in 
numerical order, up to the last implemented attribute. Any unimplemented attributes in the 
response shall use the default attribute values. 


At the instance level, the order of the attributes returned in the Get_Attributes_AIl reponse shall 
be as follows: 
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Table 5-5.11 Instance Level Get_Attributes_All Response Data 


Attribute ID Data Type Attribute Name Default Value 
(if not implemented) 
1 UDINT Interface Speed 
2 DWORD Interface Flags 
2 ARRAY of 6 USINTs Physical Address 
4 STRUCT of 11 UDINTs Interface Counters 0 
Ss STRUCT of 12 UDINTs Media Counters 0 
6 STRUCT of: Interface Control! 
WORD Control Bits 0 
UINT Forced Interface Speed 0 
wa USINT Interface Type 0 
8 USINT Interface State 0 
9 USINT Admin State 0 
10 SHORT_STRING Interface Label Zero-length string 
dt STRUCT of: Interface Capability 
DWORD Capability Bits 
STRUCT of: Speed/Duplex Options 
USINT Speed/Duplex Array Count 
ARRAY of: Speed/Duplex Array 
STRUCT of: Speed/Duplex Pair 
UINT Interface Speed 
USINT Interface Duplex Mode 
12 STRUCT of 8 ULINTS HC Interface Counters 0 
13 STRUCT of 6 ULINTS HC Media Counters 0 


Table Footnotes 


1, The default value for this attribute is an otherwise invalid combination (since Auto Negotiation is disabled in 
Control Bits, but Forced Interface Speed is zero) and can therefore be used to determine that the attribute is not 


supported. 


Important: Insert the default value for all unsupported attributes that are included in the 
response. 

The lengths of the Interface Label and Speed/Duplex Options are not known before issuing the 
Get_Attributes_All service request. Implementers shall be prepared to accept a response 
containing the maximum size of the Interface Label (65 USINTs) and an Interface Capability 
attribute with at least 10 elements in its Speed/Duplex Array. 
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5-5.5 Class-Specific Services 


The Ethernet Link Object shall support the following class-specific services: 


Table 5-5.12 Class Specific Services 


Service Need in Implementation 
Code Class Instance Service Name Description of Service 
Ox4C na Conditional ! Get_and_Clear Gets then clears the specified attribute 


(Interface Counters, Media Counters, HC 
Interface Counters, or HC Media 
Counters). 


Table Footnotes 


1 The Get_and_Clear service shall only be implemented if the Interface Counters, Media Counters, HC 
Interface Counters or HC Media Counters are implemented. 


5-5.5.1 Get_and_Clear Service 


The Get_and_Clear service is a class-specific service. It is only supported for the Interface 
Counters, Media Counters, HC Interface Counters, or HC Media Counters attributes. The | 
Get_and_Clear response shall be the same as the Get_Attribute_Single response for the 

specified attribute. After the response is built, the value of the attribute shall be set to zero. 
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5-5.6 Behavior 


The behavior of the Ethernet Link Object shall be as illustrated in Diagram below. 
Figure 5-5.1 Diagram Showing the Behavior of the Ethernet Link Object 
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5-6 Device Level Ring (DLR) Object 
Class Code: 47 Hex 
5-6.1 Scope 


The Device Level Ring (DLR) Object provides the configuration and status information 
interface for the DLR protocol. The DLR protocol is a layer 2 protocol that enables the use of 
an Ethernet ring topology. The DLR protocol is fully specified in Chapter 9. The DLR Object 
provides the CIP application-level interface to the protocol. 


The DLR Object shall be implemented in all multi-port EtherNet/IP devices that support the 
Device Level Ring protocol. 


Devices shall implement no more than one instance of the DLR Object. Support for the DLR 
protocol on multiple pairs of ports is future enhancement that is at the present time undefined. 


5-6.2 Revision History 


Since the initial release of this object class definition changes have been made that require a 
revision update of this object class. The table below represents the revision history: 


Revision Description 
1 Initial Definition at First Release of Specification (obsolete) 
2 Instance Attribute 10 changed to Required (vs. Conditional) and added to non-supervisor 


Get_Attributes_All response. 

Added (Required) instance attribute 12. 

Added attribute 12 to Get_Attributes_All responses. 

Add Restart_Sign_On Conditional Service to Object Specific services. 


3 Added conditional attribute 13 for redundant gateway configuration 

Added conditional attribute 14 for redundant gateway status 

Added conditional attribute 15 for active gateway address 

Added conditional attribute 16 for active gateway Precedence 

Added redundant gateway capability bit in attribute 12, capability flags 

Added Flush_Tables frame support capability bit in attribute 12, capability flags 
Added Get_Attributes_All responses for redundant gateway devices 

Revision 2 is obsolete 


5-6.3 Attributes 
5-6.3.1 Class Atributes 
Table 5-6.1 Class Attributes 


Attrib Need in Access Data Description of ry 
ID Implementation | Rule ISN ELITE Type Attribute siieuTissd). alba 
1 Conditional ! Get NV | Revision UINT __| Revision of this The current value assigned to 
object this attribute is 3 
2 thru7 | These class attributes are optional and are described in Volume 1, Chapter 4 of the CIP Common specification. 


Table Footnotes 


1 Required if the Revision value is greater than 1 
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5-6.3.2 Instance Attributes 
Table 5-6.2 Instance Attributes 


Attrib Need in Access NV None Data Description of 


ID Implem Rule Type ‘Attribute Semantics of Values 


1 Required Get Vv Network USINT Current network 0 indicates “Linear” 
Topology topology mode 1 indicates “Ring” 
See section 5-6.3.3 


2 ‘| Required Get Vv Network Status USINT Current status of | 0 indicates “Normal” 
network 1 indicates “Ring Fault” 
2? indicates 
“Unexpected Loop 
Detected” 

3 indicates “Partial 
Network Fault” 

4 indicates “Rapid 
Fault/Restore Cycle” 
See section 5-6.3.4 


3 | Conditional ' | Get Vv Ring Supervisor | USINT Ring supervisor 0 — indicates the node is 
Status active status flag | functioning as a backup 
1 — indicates the device 
is functioning as the 
active ring supervisor. 
2 — indicates the device 
is functioning as a 
normal ring node. 

3 — indicates the device 
is operating in a non- 
DLR topology 

4 — indicates the device 
cannot support the 
currently operating ring 
parameters (Beacon 
Interval and/or Beacon 
Timeout) 

See section 5-6.3.5 


— 5-40 - 
Edition 1.18 
SINGLE SUBSCRIPTION ONLY; SUBSCRIPTION TERMS AND CONDITIONS OUTLINED ON PAGE (iii) 


Volume 2: EtherNet/IP Adaptation of CIP, Chapter 5: Object Library 


DLR Object, Class Code: 47 Hex 


Attrib Need in Access Data Description of ry 
ID Lama Rule NV Name Type ‘Attribute Semantics of Values 
4 | Conditional ' | Set NV_ {Ring Supervisor | Struct of: | Ring Supervisor See section 5-6.3.6 
Config configuration 
parameters 
Ring Supervisor | BOOL. Ring supervisor TRUE indicates the 
Enable enable flag device is configured as 
a ring supervisor. 
FALSE indicates device 
is configured as a 
normal ring node 
Default=F ALSE 
Ring Supervisor | USINT Precedence of a Numerically higher 
Precedence ring supervisor in _ | value indicates higher 
network with precedence 
multiple ring Default=0 
supervisors 
Beacon Interval | UDINT Duration of ring Beacon interval in 
beacon interval microseconds. 
Default=400 
microseconds 
Beacon Timeout | UDINT Duration of ring Beacon timeout in 
beacon timeout microseconds. 
Default=1960 
microseconds 
DLR VLAN ID _ | UINT VLAN ID to use in | Value range is 0-4094 
ring protocol Default=0 
messages 
5 Conditional ' | Set v Ring Faults UINT Number of ring See section 5-6.3.7 
Count faults since power 
up 
6 | Conditional ' | Get Vv Last Active Node | STRUCT | Last active node at | See section 5-6.3.8 
on Port 1 of: the end of chain 
through port | of 
active ring 
supervisor during 
ring fault 
UDINT | Device IP Address | A value of 0 indicates 
no IP Address has been 
configured for the 
device. Initial value 
shall be 0. 
ARRAY | Device MAC Ethernet MAC address 
of 6 Address 
USINTs 
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Attrib | Need in Access Data Description of 4 
ID Implem Rule aN! NET Type Attribute ES arr ES 
7 | Conditional ' | Get v Last Active Node | STRUCT | Last active node at | See section 5-6.3.9 
on Port 2 of: the end of chain 
through port 2 of 
active ring 
supervisor during 
ring fault 

UDINT Device IP Address | A value of 0 indicates 
no IP Address has been 
configured for the 
device 

ARRAY | Device MAC Ethernet MAC address 

of 6 Address 

USINTs 

8 | Conditional ' | Get Vv Ring Protocol UINT Number of devices | See section 5-6.3.10 
Participants in ring protocol 
Count participants list 
9 | Conditional ' | Get Vv Ring Protocol ARRAY _ | List of devices See section 5-6.3.11 
Participants List | of : participating in 
ring protocol 

STRUCT 

of: 

UDINT Device IP Address | A Value of 0 indicates 
no IP Address has been 
configured for the 
device 

ARRAY | Device MAC Ethernet MAC address 

of 6 Address 

USINTs 

10 | Required Get Vv Active Supervisor | STRUCT | IP and/or MAC See section 5-6.3.12 
Address oft address of the 
active ring 
supervisor 
UDINT Supervisor IP A Value of 0 indicates 

Address no IP Address has been 
configured for the 
device 

ARRAY | Supervisor MAC __| Ethernet MAC address 

of 6 Address 

USINTs 

11 | Conditional ' | Get Vv Active Supervisor | USINT Precedence value _| See section 5-6.3.13 
Precedence of the active ring 
supervisor 
12. | Required Get NV_ | Capability Flags |DWORD | Describes the DLR | See section 5-6.3.14 
capabilities of the 
device 
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Attrib Need in Access Data Description of ry 
ID lama Rule NV Name Type ‘Attribute Semantics of Values 
13 | Conditional ? | Set NV__| Redundant STRUCT | Redundant See section 5-6.3.15 
Gateway Config | of: Gateway 
configuration 
parameters 
Redundant BOOL. Redundant TRUE indicates the 
Gateway Enable gateway enable device is configured as 
flag a redundant gateway 
FALSE indicates device 
is not configured as a 
redundant gateway 
Default=FALSE 
Gateway USINT Precedence of a Numerically higher 
Precedence gateway in value indicates higher 
network with Precedence 
multiple gateways | Default=0 
Advertise Interval | UDINT __ | Duration of active | Advertise Interval in 
gateway Advertise | microseconds. 
Interval Default=2000 
microseconds 
Advertise UDINT Duration of active | Advertise Timeout in 
Timeout gateway Advertise | microseconds. 
Timeout Default=5000 
microseconds 
Learning Update | BOOL Learning Update | TRUE indicates all 


Enable 


Enable flag 


DLR nodes will send 
Learning_Update frame 
after gateway 
switchover 

FALSE indicates DLR 
nodes will not send 
Learning_Update frame 
after gateway 
switchover 
Default=>TRUE 
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Attrib Need in Access Data Description of 


ID Implem Rule Type Attribute 


NV Name Semantics of Values 


14 | Conditional * | Get Vv Redundant USINT Current Status of | 0 — indicates the device 


Gateway Status gateway device is functioning as a non- 
gateway DLR node 
(gateway not enabled) 

1 — indicates the device 
is functioning as a 
backup gateway 

2 - indicates the device 
is functioning as the 
active gateway 

3 — indicates gateway 
fault state due to loss of 
communication on 
uplink port 

4 — indicates the device 
cannot support the 
currently operating 
gateway parameters 
(Advertise Interval 
and/or Advertise 
Timeout) 

5 — indicates gateway 
fault state due to partial 
network fault (see 
Section 9-5.8.3.7) 
6-255 — Reserved 

See section 5-6.3.16 


15 | Conditional * | Get v Active Gateway |STRUCT | IP and/or MAC See section 5-6.3 


ails 
Address of: address of the 
active gateway 
device 


UDINT Active gateway IP_| A value of 0 indicates 
Address. no IP Address has been 
configured for this 
device 


Array of 6 | Active gateway | Ethernet MAC address 
USINTs | MAC Address 


16 | Conditional ? | Get v Active Gateway | USINT Precedence value _| See section 5-6.3.18 


Precedence of the active 
gateway 


Table Footnotes 


1 


2 


Shall be implemented for devices capable of functioning as a ring supervisor. Shall not be implemented by non- 
supervisor devices. 

Shall be implemented for devices capable of functioning as a redundant gateway. Shall not be implemented by non- 
redundant gateway devices. 


If the device is capable of detecting reception of frames that it sent, it shall report the “Unexpected Loop Detected” 
value. 


5-6.3.3 


Network Topology — Attribute 1 


The Network Topology attribute indicates the current network topology mode. A value of 0 
shall indicate “Linear” topology. A value of 1 shall indicate “Ring” topology. The value of the 
attribute shall correspond to the DLR State specified in Chapter 9. 
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When a supervisor-capable device is enabled as a ring supervisor, the Network Topology 
attribute shall always indicate “Ring” except in the case where the device cannot support the 
current operating ring parameters. When a supervisor-capable device is not enabled as a ring 
supervisor, or is enabled as a ring supervisor but can’t support the current operating ring 
parameters, or the device is not a supervisor-capable device, the device shall initially indicate 
“Linear”, then shall transition between “Ring” and “Linear” modes as specified in Chapter 9. 


Network Status - Attribute 2 


The Network Status attribute provides current status of the network based the device’s view of 
the network, as specified in the DLR behavior in Chapter 9. Table 5-6.3 shows the possible 
values: 


Table 5-6.3 Network Status values 


pctyorks Description 
Status value pt 
0 Normal operation in both Ring and Linear Network Topology modes. 


1 Ring Fault. A ring fault has been detected. Valid only when Network Topology is Ring. 


2 Unexpected Loop Detected. A loop has been detected in the network. Valid only when the 
Network Topology is Linear. 


3 Partial Network Fault. A network fault has been detected in one direction only. Valid only 
when Network Topology is Ring and the node is the active ring supervisor. 


4 Rapid Fault/Restore Cycle. A series of rapid ring fault/restore cycles has been detected, per 
the criteria in Chapter 9. Similar to the Partial Network Fault status, the supervisor remains 
ina state with forwarding blocked on its ring ports. The condition must be cleared 
explicitly via the “Clear Rapid Faults” service. 


Ring Supervisor Status — Attribute 3 


The Ring Supervisor Status attribute indicates the device’s status as a ring supervisor. Table 5- 
6.4 shows the possible values: 


Table 5-6.4 Ring Supervisor Status values 


Supervisor ere 
Description 
Status value L 
0 Indicates the device is functioning as a backup supervisor. 
1 Indicates the device is functioning as the active ring supervisor. 
2 Indicates the device is functioning as a normal ring node (supervisor not enabled). 
3 Indicates the device is functioning in a non-DLR topology (supervisor not enabled, and no 
other supervisor is present). 
4 Indicates the device cannot support the currently operating ring parameters (Beacon 
Interval and/or Beacon Timeout). 


Ring Supervisor Config - Attribute 4 


The Ring Supervisor Config attribute contains the configuration parameters needed for ring 
operation: Supervisor Precedence, Beacon Interval, Beacon Timeout, VLAN ID, Supervisor 
Enable/Disable. 


If the device is the active supervisor, changes to the attribute shall be applied immediately. 
When the Supervisor Precedence, Beacon Interval, Beacon Timeout or VLAN ID are changed 
on the active ring supervisor, the ring supervisor shall cease sending Beacon frames for two 
beacon timeout periods then shall resume sending Beacon frames using the new parameters. 


— 5-45 — 
Edition 1.18 
SINGLE SUBSCRIPTION ONLY; SUBSCRIPTION TERMS AND CONDITIONS OUTLINED ON PAGE (iii) 


Volume 2: EtherNet/IP Adaptation of CIP, Chapter 5: Object Library 


5-6.3.6.1 


5-6.3.6.2 


5-6.3.6.3 


5-6.3.6.4 


DLR Object, Class Code: 47 Hex 


Backup ring supervisors shall obtain values for the Beacon Interval, Beacon Timeout and 
VLAN ID from the Beacon frame sent by the active ring supervisor, and shall store those 
values in non-volatile storage. If the obtained values cannot be supported by the device (e.g., 
Beacon Interval too small), the device shall set the Ring Supervisor Status attribute as noted in 
the attribute description, shall report a minor recoverable fault via the Identity object Status (5) 
attribute and shall not take over as active supervisor after a ring reconfiguration. 


When the Ring Supervisor Config attribute is modified on a backup supervisor, the behavior 
depends on the backup supervisor’s new precedence value compared to the active supervisor’s 
precedence value: 


e New backup precedence value is greater than the current active ring supervisor’s precedence 
or of equal precedence with numerically higher MAC address than active supervisor MAC 
address: backup shall immediately begin sending Beacon frames with the new parameters. 

e New backup precedence value is less than the active supervisor’s precedence or of equal 
precedence with numerically lower MAC address than active supervisor MAC address: 
modification to the Beacon Interval, Beacon Timeout, and VLAN ID shall be ignored. 


Attempts to set invalid Ring Supervisor Config values shall result in error code 0x09 (Invalid 
attribute value) returned from the set service, regardless of whether the device is an active or 
backup supervisor. 


Ring Supervisor Enable 


The Ring Supervisor Enable item enables or disables the ring supervisor function in a 
supervisor-capable device. A value of TRUE enables the supervisor function. A value of 
FALSE disables the supervisor function. The default value is FALSE. 


Ring Supervisor Precedence 


The Ring Supervisor Precedence item contains the user-assigned precedence value given to the 
ring supervisor. When multiple ring supervisors are enabled, the precedence value allows the 
user to configure the order in which the configured supervisors select the active supervisor. 


The ring supervisor precedence must be chosen from the range 0-255, with numerically higher 
values indicating higher precedence. The default value shall be 0. 


When more than one supervisor is enabled the supervisor with highest precedence becomes 
active ring supervisor, in accordance with Chapter 9. If multiple supervisors have the same 
precedence, the supervisor with the numerically higher MAC address becomes the active 
supervisor 


Beacon Interval 


The Beacon Interval item contains the interval in microseconds that the ring supervisor shall 
use in generating beacon frames. Per the DLR protocol specification in Chapter 9, the default 
value shall be 400 microseconds. Supervisors shall support a range from 400 microseconds to 
100 milliseconds. Supervisors may support a Beacon Interval smaller than 400 microseconds, 
but this is not required. The absolute minimum Beacon Interval is 100 microseconds. 


Beacon Timeout 


The Beacon Timeout item contains the number of microseconds the ring supervisor shall wait 
for a beacon frame before declaring a beacon timeout. 
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The default value shall be 1960 microseconds, which is based on a nominal network size of 50 
nodes and 100Mbps, full-duplex operation (refer to the Performance Calculations in Chapter 
9). The user may wish to change the Beacon Timeout for other exceptional network 
circumstances (e.g., very large networks or very small high-performance motion networks). 


The Beacon Timeout shall be at least 2 times the Beacon Interval value. If the Beacon Interval 
is changed and the Beacon Timeout becomes less than 2 times the Beacon Interval, the 
supervisor shall adjust the Beacon Timeout to be 2 times the Beacon Interval. 


Supervisors shall support a range from 800 microseconds to 500 milliseconds. Supervisors may 
support a Beacon Timeout of smaller than 800 microseconds but this is not required. The 
absolute minimum Beacon Timeout is 200 microseconds. 


DLR VLAN ID 


The DLR VLAN ID contains the VLAN ID to be used in the DLR protocol frames. The DLR 
VLAN ID shall be used for all DLR protocol frames originated by the device, when the device 
is operating as the active ring supervisor. Devices that are not the active ring supervisor shall 
use the VLAN ID obtained from the active supervisor’s frames (refer to Chapter 9 for 
additional details). 


The VLAN ID value shall be in the range 0-4094. The default value shall be 0 (indicating no 
VLAN). 


Ring Faults Count — Attribute 5 


The Ring Faults Count attribute contains the number of times since power up that the device 
has detected a ring fault, as either active or backup supervisor. If the Ring Supervisor Enable is 
set to FALSE, the Ring Faults Count shall be set to 0. The Ring Faults Count rolls over to 0 
after it reaches its maximum value. 


The attribute may also be reset to 0 via the Set_Attribute_Single service. Values other than 0 
shall result in an error response. 


Last Active Node on Port 1 — Attribute 6 


The Last Active Node on Port | attribute contains the IP address and/or Ethernet MAC address 
of the last node reachable through port | of an active ring supervisor. The value of the attribute 
is obtained via the Link_Status/Neighbor Status frames, as specified in Chapter 9. 

On transition to FAULT_STATE, this attribute shall remain clear until the supervisor receives 
Link/Neighbor Status information. 


On transition from FAULT_STATE to NORMAL_STATE, the value of the attribute shall be 
retained, to aid in diagnosing the previous ring fault. 

The initial values of IP address and Ethernet MAC address shall be 0. When the device is not 
enabled as a ring supervisor, or is operating as the backup supervisor the IP address and 
Ethernet MAC address shall be 0. 


Last Active Node on Port 2 - Attribute 7 


The Last Active Node on Port 2 attribute contains the IP address and/or Ethernet MAC address 
of the last node reachable through port 2 of an active ring supervisor. The value of the attribute 
is obtained via the Link_Status/Neighbor Status frames, as specified in Chapter 9. 


On transition to FAULT_STATE, this attribute shall remain clear until the supervisor receives 
Link/Neighbor Status information. 
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On transition from FAULT_STATE to NORMAL_STATE, the value of the attribute shall be 
retained, to aid in diagnosing the previous ring fault. 


The initial values of IP address and Ethernet MAC address shall be 0. When the device is not 
enabled as a ring supervisor, or is operating as the backup supervisor the IP address and 
Ethernet MAC address shall be 0. 


Ring Protocol Participants Count — Attribute 8 


This attribute contains the number of members in the Ring Protocol Participants List attribute. 
The count and the list are gathered by the active ring supervisor through Sign_On frame as 
specified in Chapter 9. 


If the device is not the active supervisor, the attribute shall be set to 0. 
Ring Protocol Participants List —- Attribute 9 


The Ring Protocol Participants List attribute contains the list of ring nodes participating in ring 
protocol. The participants list is gathered by the active ring supervisor via the Sign_On frame 
(see Chapter 9). 


Since the size of the Ring Protocol Participants List could be large, depending on the number of 
nodes participating in the ring, this attribute shall be accessible with the Get_Member service. 


Clients may elect to use the Get_Attribute_Single service to read the Ring Protocol Participants 
List. If the participants list is too large, the DLR Object shall return error code 0x11 (Reply 
Data Too Large). 


If the device is not active supervisor, status code 0x0C (Object State Conflict) shall be returned. 
If the number of participants received as a result of the Sign_On process exceeds the capacity 
of the supervisor’s Ring Protocol Participants List, the last entry in the list shall be all Oxff’s 
(Ox fhrfrrrrrrftrrtrtttt). 

Active Supervisor Address — Attribute 10 


This attribute contains the IP address and/or Ethernet MAC address of the active ring 
supervisor. The initial values of IP address and Ethernet MAC address shall be 0, until the 
active ring supervisor is determined. 


Active Supervisor Precedence — Attribute 11 


This attribute contains the precedence value of the active ring supervisor. The initial value 
shall be 0, until the active ring supervisor is determined. 
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Capability Flags — Attribute 12 
The Capability Flags describe the DLR capabilities of the device. 
Table 5-6.5 Capability Flags 


Bit(s): Called Definition 
0 Announce-based Ring Node! | Set if device’s ring node implementation is based on processing of 
Announce frames. See Volume 2, Chapter 9-5.4.3 for more 
information. 
1 Beacon-based Ring Node! Set if device’s ring node implementation is based on processing of 
Beacon frames. See Volume 2, Chapter 9-5.4.2 for more information. 
2-4 Reserved Shall be set to zero. 
5: Supervisor Capable Set if device is capable of providing the supervisor function. 
6 Redundant Gateway Capable | Set if device is capable of providing the redundant gateway function. 
7 Flush_Table frame Capable | Set if device is capable of supporting the Flush_Tables frame. 
8-31 Reserved Shall be set to zero. 


Table Footnotes 


1 Bits 0 and 1 are mutually exclusive. Exactly only one of these bits shall be set in the attribute value that a device 
reports. 


Redundant Gateway Config — Attribute 13 


The Redundant Gateway Config attribute contains the configuration parameters needed for 
redundant gateway operation: Gateway enable/disable, Gateway Precedence, Advertise 
Interval, Advertise Timeout and Learning Update enable/disable. 


If the device is the active gateway, changes to the attribute shall be applied immediately. When 
the Gateway Precedence, Advertise Interval, Advertise Timeout or Learning Update 
enable/disable are changed on the active gateway, the active gateway shall cease sending 
Advertise frames for 1.5 times old Advertise Timeout period and then shall resume sending 
Advertise frames using the new parameters. 


Backup gateway devices shall obtain values for the Advertise Interval, Advertise Timeout and 
Learning Update enable/disable from the Advertise frame sent by the active gateway, and shall 
store those values in non-volatile storage. If the obtained values cannot be supported by the 
device (e.g., Advertise Interval too small), the device shall set the Redundant Gateway Status 
attribute as noted in the attribute description, shall report a minor recoverable fault via the 
Identity object Status (5) attribute, and shall not take over as active gateway after a gateway 
reconfiguration. 


When the Redundant Gateway Config attribute is modified on a backup gateway, the behavior 
depends on the backup gateway’s new Precedence value compared to the active gateway’s 
Precedence value: 


e New backup Precedence value is greater than the current active gateway’s Precedence or of 
equal Precedence with numerically higher MAC address than active gateway MAC address: 
backup shall immediately begin sending Advertise frames with the new parameters (see 
Section 9-5.10.4). 

e New backup Precedence value is less than the active gateway’s Precedence or of equal 
Precedence with numerically lower MAC address than active gateway MAC address: 
Advertise Interval, Advertise Timeout and Learning Update enable/disable shall be ignored. 
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Attempts to set invalid Redundant Gateway Config values shall result in error code 0x09 
(Invalid attribute value) returned from the set service, regardless of whether the device is an 
active or backup gateway. 


Redundant Gateway Enable 


The Redundant Gateway Enable item enables or disables the gateway function in a redundant 
gateway-capable device. A value of TRUE enables the gateway function. A value of FALSE 
disables the gateway function. The default value is FALSE. 


Gateway Precedence 


The Gateway Precedence item contains the user-assigned Precedence value given to a gateway. 
When multiple gateways are enabled, the Precedence value allows the user to configure the 
order in which the configured gateways select the active gateway. 


The gateway Precedence must be chosen from the range 0-255, with numerically higher values 
indicating higher Precedence. The default value shall be 0. 


When more than one gateway is enabled the gateway with highest Precedence becomes active 
gateway, in accordance with Chapter 9. If multiple gateways have the same Precedence, the 
gateway with the numerically higher MAC address becomes the active gateway. 


Advertise Interval 


The Advertise Interval item contains the interval in microseconds that the active gateway shall 
use in generating Advertise frames. Per the DLR protocol specification in Chapter 9, the 
default value shall be 2000 microseconds. Gateways shall support a range from 1000 
microseconds to 100 milliseconds. Gateways may support an Advertise Interval smaller than 
000 microseconds, but this is not required. The absolute minimum Advertise Interval is 200 
microseconds. 


Advertise Timeout 


The Advertise Timeout item contains the number of microseconds a backup gateway shall wait 
for an Advertise frame before declaring an Advertise Timeout. 


The default value shall be 5000 microseconds, which is based on a nominal network size of 50 
nodes and 100Mbps, full-duplex operation (refer to the Performance Calculations in Chapter 
9). The user may wish to change the Advertise Timeout for exceptional network circumstances 
(e.g., very large networks or very small high-performance motion networks). 


[he Advertise Timeout shall be at least 2.5 times the Advertise Interval value. If the Advertise 
Interval is changed and the Advertise Timeout becomes less than 2.5 times the Advertise 
Interval, the gateway shall adjust the Advertise Timeout to be 2.5 times the Advertise Interval. 


Gateways shall support a range from 2500 microseconds to 500 milliseconds. Gateways may 
support a Advertise Timeout of smaller than 2500 microseconds but this is not required. The 
absolute minimum Advertise Timeout is 500 microseconds. 
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5-6.3.15.5 Learning Update Enable 


The Learning Update Enable item enables/disables transmission of Learning_Update frames by 
DLR nodes when they receive Flush_Tables frame from active gateway. This parameter is 
encoded by active gateway in Flush_Tables frame and sent to DLR nodes. The 
Learning_Update frames from DLR devices accelerate the new network topology learning by 
all non-DLR switches outside DLR network after an active gateway switchover. A value of 
TRUE enables the learning update function. A value of FALSE disables the learning update 
function. The default value is TRUE. 


5-6.3.16 Redundant Gateway Status — Attribute 14 


The Redundant Gateway Status attribute indicates the device’s status as a gateway. Table 5-6.6 
shows the possible values: 


Table 5-6.6 Redundant Gateway Status values 


Redundant Description 
Gateway Status 
value 
0 Indicates the device is functioning as a non-gateway DLR node (gateway not enabled). 
1 Indicates the device is functioning as a backup gateway. 
2 Indicates the device is functioning as the active gateway. 
3 Indicates gateway fault state due to loss of communication on uplink port. 
4 Indicates the device cannot support the currently operating gateway parameters (Advertise 
Interval and/or Advertise Timeout). 
3: Indicates gateway fault state due to partial network fault. 


5-6.3.17 Active Gateway Address — Attribute 15 


This attribute contains the IP address and/or Ethernet MAC address of the active gateway 
device. The initial values of IP address and Ethernet MAC address shall be 0, until the active 
gateway is determined. 


5-6.3.18 | Active Gateway Precedence — Attribute 16 


This attribute contains the Precedence value of the active gateway device. The initial value 
shall be 0, until the active gateway is determined. 


5-6.4 Common Services 
Table 5-6.7 DLR Object Common Services 


i Need in Implementation 

Sraniluo(Coge E Service Name Description of Service 
(Hex) Class Instance 
Ox01 Optional Required Get_Attributes_All Returns multiple attributes in 

numerical order. 

Ox0E Optional Required Get_Attribute_Single Returns a single attribute 
0x10 n/a Conditional ' | Set_Attribute_Single Modifies a single attribute 
0x18 n/a Conditional > | Get_Member Returns members of attribute 


Table Footnotes 

1 This service must be implemented for devices capable of functioning as a ring supervisor and/or redundant 
gateway. 

2 Required for access to the Ring Protocol Participants List. The member services extended protocol for multiple 
sequential members shall be supported (see Volume 1, Appendix A). 
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Get_Attributes_All Response 
Class Level 


At the class level, the Get_Attributes_All response shall contain the class attributes in 
numerical order, up to the last implemented attribute. Any unimplemented attributes in the 
response shall use the default attribute values. 


Instance Level 


At the instance level, the Get_Attributes_All response varies depending on the revision of the 
object and the device's capabilities. The response format can be differentiated by the response 
length. 


The response length for an Object Revision 1, non-supervisor device is 2 bytes. 


Table 5-6.8 Get_Attributes_All Response — Object Revision 1, non-supervisor device 


Attribute ID Data Type Name 
1 USINT Network Topology 
2 USINT Network Status 
The response length for an Object Revision 1, supervisor-capable device is 50 bytes. 
Table 5-6.9 Get _Attributes_All Response — Object Revision 1, supervisor-capable device 
Attribute ID Data Type Name 
1 USINT Network Topology 
2 USINT Network Status 
3 USINT Ring Supervisor Status 
4 Struct of: Ring Supervisor Config: 
BOOL Ring Supervisor Enable 
USINT Ring Supervisor Precedence 
UDINT Beacon Interval 
UDINT Beacon Tiimeout 
UINT DLR VLAN ID 
5 UINT Ring Faults Count 
6 Struct of: | Last Active Node on Port 1 
UDINT Device IP Address 
ARRAY of 6 | Device MAC Address 
USINTs 
7 Struct of: | Last Active Node on Port 2 
UDINT Device IP Address 
“ARRAY of 6 [Device MAC Address 
USINTs 
UINT Ring Protocol Participants Count 
10 Struct of: Active Supervisor Address 
UDINT Device IP Addres: 
ARRAY of 6 | Device MAC Address 
USINTs 
11 USINT Active Supervisor Precedence 
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The response length for an Object Revision 2, non-supervisor—capable device is 16 bytes. 


Table 5-6.10 Get_Attributes_All Response - Object Revision 2, non supervisor device 


Attribute ID | Data Type Name 
1 USINT | Network Topology 
2 USINT _ | Network Status 
10 Struct of: | Active Supervisor Address. 


UDINT _ | Device IP Address 


ARRAY of | Device MAC Address 
6 USINTs 


12 DWORD | Capability Flags 


In all other cases, the Get_Attributes_All response (see Table 5-6.11) shall contain the instance 
attributes | through 8 and 10 through 16, up to the last implemented attribute. Any 
unimplemented attributes in the response shall use the default value specified. 


The response length for an Object Revision 2, supervisor—capable device is 54 bytes. 

The response length for an Object Revision 3, non-supervisor, non-gateway device is 54 bytes. 
The response length for an Object Revision 3, supervisor, non-gateway device is 54 bytes. 

The response length for an Object Revision 3, gateway-capable device is 77 bytes. 

Table 5-6.11 Get_Attributes_All Response — All other cases 


Attribute ID | Data Type Name Default Value 
(if not implemented) 
1 USINT _ | Network Topology 
2 USINT __| Network Status 
3 USINT | Ring Supervisor Status OxFF — Not Applicable 
4 Struct of: | Ring Supervisor Config 
BOOL _ | Ring Supervisor Enable 
USINT | Ring Supervisor Precedence 
UDINT | Beacon Interval 0 
UDINT | Beacon Timeout 0 
UINT DLR VLAN ID 0 
5 UINT __ | Ring Faults Count 0) 
6 Struct of: | Last Active Node on Port | 
UDINT | Device IP Address 0 
ARRAY of | Device MAC Address All zeroes 
6 USINTs 
7 Struct of: | Last Active Node on Port 2 
UDINT | Device IP Address 0 
ARRAY of | Device MAC Address All zeroes 
6 USINTs 
8 UINT Ring Protocol Participants Count OxFFFF — Not 
Applicable 
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Attribute ID | Data Type Name Default Value 
(if not implemented) 
10 Struct of: | Active Supervisor Address 
UDINT | Device IP Address 
ARRAY of | Device MAC Address 
6 USINTs 
11 USINT | Active Supervisor Precedence 0 
12 DWORD | Capability Flags 
13 Struct of: | Redundant Gateway Configuration 
BOOL | Redundant Gateway Enable 
USINT | Gateway Precedence 
UDINT | Advertise Interval 
UDINT | Advertise Timeout 
BOOL _ | Learning Update Enable 
14 USINT | Redundant Gateway Status 
15 Struct of; | Active Gateway Address 
UDINT | Device IP Address 
ARRAY of | Device MAC Address 
6 USINTs 
16 USINT | Active Gateway Precedence 
5-6.6 Class-Specific Services 
The DLR Object shall support the following class-specific services: 
Table 5-6.12 DLR Object Class-Specific Services 
Service | Need in Implementation 
Code Service Name Description of Service 
(Hex) Class Instance 
Ox4B | n/a Conditional ' | Verify_Fault_Location Causes ring supervisor to verify fault location by 
issuing Locate_Fault ring 
protocol message to ring nodes and update Last 
Active Node | and Last Active Node 2 attributes. 
Ox4C | n/a Conditional ' | Clear_Rapid_Faults Clears the Rapid Fault/Restore Cycle Detected 
condition in the ring supervisor, allowing the 
supervisor to return to normal operation. 
Ox4D_ | n/a Conditional ' | Restart_Sign_On Restart Sign On process and refresh DLR 
participants list. 
Ox04E [n/a Conditional? | Clear_Gateway_Partial_Fault | Clears the partial network fault condition in the 
gateway device, allowing the gateway to return 
to normal operation. 


Table Footnotes: 


1 This service shall be implemented for devices capable of functioning as a ring supervisor 


2 This service shall be implemented for devices capable of functioning as a redundant gateway 
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Verify_Fault_Location Service 


The Verify_Fault_Location service shall cause an active ring supervisor to verify a ring fault 
location by retransmitting the Locate_Fault frame to ring nodes (see Chapter 9). The Last 
Active Node 1 and Last Active Node 2 attributes shall be updated based on the response to the 
Locate_Fault frame. 


There are no parameters for either the Verify_Fault_Location request or reply. 


If the Verify _Fault_Location service is received when the supervisor is not enabled, or is 
currently the backup supervisor, or is the active supervisor but not in fault state, status code 
Ox0C (Object State Conflict) shall be returned, and the Last Active Node 1 and Last Active 
Node 2 attributes shall be set to 0. 


Clear_Rapid_Faults Service 


[The Clear_Rapid_Faults service shall clear the condition where the ring supervisor has detected 
a cycle of rapid ring fault/restore (as defined in Chapter 9). Upon clearing the condition, the 
ring supervisor shall return to normal operation. 


If the Clear_Rapid_Faults service is received when the supervisor is not enabled, or is currently 
the backup supervisor, or is the active supervisor but not in the rapid fault/restore condition, 
status code Ox0C (Object State Conflict) shall be returned. 


Restart_Sign_On Service 


The Restart_Sign_On service shall restart Sign On process (see Volume 2, Chapter 9-5.5.2.3 
Sign On for more information) by active ring supervisor, if it is not currently in progress. 


If the Restart_Sign_On service is received when the supervisor is not enabled, or is currently 
the backup supervisor, or is the active supervisor but not in the NORMAL_STATE, status code 
Ox0C (Object State Conflict) shall be returned. If the Restart_Sign_On service is received when 
a prior Sign On process is in progress, success shall be returned and the request shall be 
ignored 


Clear_Gateway_Partial_Fault Service 


The Clear_Gateway_Partial_Fault service shall clear the condition where the gateway has 
detected a partial network fault (as defined in Chapter 9). Upon clearing the condition, the 
gateway shall execute state machine as specified in Chapter 9. 


If the Clear_Gateway_Partial_Fault service is received when the gateway is not enabled, or is 
not in partial network fault condition, status code OxOC (Object State Conflict) shall be 
returned. 
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5-7 QoS Object 
Class Code: 48 Hex 
5-7.1 Overview 
Quality of Service (QoS) is a general term that is applied to mechanisms used to treat traffic 
streams with different relative priorities or other delivery characteristics. Standard QoS 
mechanisms include IEEE 802.1D/Q (Ethernet frame priority) and Differentiated Services 
(DiffServ) in the TCP/IP protocol suite. 
The QoS Object provides a means to configure certain QoS-related behaviors in EtherNet/IP 
devices. 
The QoS Object is required for devices that support sending EtherNet/IP messages with non- 
zero DiffServ code points (DSCP), or sending EtherNet/IP messages in 802.1Q tagged frames. 
Refer to Volume 2, Chapter 3 for EtherNet/IP device behavior related to QoS. 
5-7.2 Revision History 
Table 5-7.1 Revision History 
Revision History 
01 Initial Definition 
5-7.3 Class Attributes 
The QoS object shall support the following class attributes. 
Table 5-7.2 Class Attributes 
Attribute Need in Access Naine Data Type Description of Semantics of 
ID Implementation | Rule yp' Attribute values 
1 thru7 These class attributes are optional and are described in Chapter 4 of Volume | (the CIP Common 
specification). 
5-7.4 Instance Attributes 
The QoS object shall support the following instance attributes. 
Table 5-7.3 QoS Object Instance Attributes 
Attr Needin | Access Data Fatty 4 5 
ID Tmplem Rule NV Name Type Description of Attribute Semantics of values 
1 | Conditional ' | Set NV | 802.1Q Tag USINT | Enables or disables A value of 0 indicates 
Enable sending 802.1Q frames on | tagged frames disabled. 
CIP and IEEE 1588 A value of | indicates 
messages tagged frames enabled. 
The default value shall be 
0. 
See section 5-7.4.1 
2 | Conditional * | Set NV | DSCP PTP Event | USINT | DSCP value for PTP See section 5-7.4.2 
(IEEE 1588) event 
messages 
3 | Conditional * | Set NV | DSCP PTP USINT | DSCP value for PTP See section 5-7.4.2 
General (IEEE 1588) general 
messages 
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| Attr | Needin | Access E Data 


ID rapier Rule NV Name iene Description of Attribute Semantics of values 
4 | Required Set NV | DSCP Urgent USINT | DSCP value for CIP See section 5-7.4.2 


transport class 0/1 Urgent 
priority messages 

5 | Required Set NV | DSCP Scheduled | USINT | DSCP value for CIP See section 5-7.4.2 
transport class 0/1 
Scheduled priority 
messages 

6 | Required Set NV | DSCP High USINT | DSCP value for CIP See section 5-7.4.2 
transport class 0/1 High 
priority messages 

7 |Required Set NV | DSCP Low USINT | DSCP value for CIP See section 5-7.4.2 
transport class 0/1 low 
priority messages 

8 | Required Set NV | DSCP Explicit USINT | DSCP value for CIP See section 5-7.4.2 
explicit messages 
(transport class 2/3 and 
UCMM) and all other 
EtherNet/IP encapsulation 
messages 


Table Footnotes 


1 Required if the device supports sending 802.1Q frames 
2 Required if the device supports CIP Sync 


5-7.4.1 802.1Q Tag Enable — Attribute 1 


The 802.1Q Tag Enable attribute enables or disables sending 802.1Q frames on CIP and IEEE 
1588 messages. When the attribute is enabled, the device shall send 802.1Q frames for all CIP 
and IEEE 1588 messages. The 802.1Q priority value shall be as specified in Volume 2, Chapter 
35 


A value of 1 shall indicate enabled. A value of 0 shall indicate disabled. The default value for 
the attribute shall be 0. A change to the value of the attribute shall take effect the next time the 
device restarts. 


Note: devices shall always use the corresponding DSCP values regardless of whether 802.1Q 
frames are enabled or disabled. 


5-7.4.2 DSCP Value Attributes — Attributes 2-8 


Attributes 2 through 8 contain the DSCP values that shall be used for the different types of 
EtherNet/IP traffic. 


Volume 2, Chapter 3-7 shows the format of the DSCP value within the IP header. Since the 
DSCP field has a size of 6 bits, the valid range of values for these attributes is 0-63. Note that 
the DSCP value, if placed directly in the ToS field in the IP header, must be shifted left 2 bits. 


Table 5-7.4 shows the default DSCP values and traffic usages. 
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Table 5-7.4 Default DCSP Values and Usages 


Attribute Traffic Type Usage Default DSCP 

DSCP PTP Event PTP (IEEE 1588) event messages 59 (‘111011’) 
DSCP PTP General PTP (IEEE 1588) general messages 47 101111") 
DSCP Urgent CIP transport class 0/1 messages with Urgent priority 55 (‘110111’) 
DSCP Scheduled CIP transport class 0/1 messages with Scheduled priority | 47 (‘101111’) 
DSCP High CIP transport class 0/1 messages with High priority 43 (‘101011’) 
DSCP Low CIP transport class 0/1 messages with Low priority 31 COI’) 
DSCP Explicit CIP UCMM 27 (O11011") 

CIP transport class 2/3 

All other EtherNet/IP encapsulation messages 


A change to the value of the above attributes shall take effect the next time the device restarts. 


Common Services 


The QoS Object provides the following common services. 
Table 5-7.5 Common Services 
Service Need in Implementation Service Description of 
Code Class Instance Name Service 
0x01 Optional N/A Get_Attributes_All See Volume 1, Appendix A 
Ox0E | Conditional ' | Required Get_Attribute_Single | See Volume 1, Appendix A 
Ox 10 N/A Required Set_Attribute_Single See Volume 1, Appendix A 


Table Footnotes 
1 Required if any class attributes are implemented 


Get_Attributes_All Response 
Class Level 


The Get_Attributes_All response shall contain the class attributes in numerical order, up to the 
last implemented attribute. Any unimplemented attributes in the response shall use the default 
attribute values. 
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5-8 Base Switch Object 
Class Code: 51 Hex 
5-8.1 Scope 


The Base Switch Object provides the CIP application-level interface to basic status information 
for a Managed Ethernet switch device. 


Devices shall implement no more than one instance of the Base Switch Object. 

5-8.2 Revision History 
This is the initial definition of the Base Switch Object. 
Table 5-8.1 Revision History 


Revision Description 
1 Initial Definition at First Release 


5-8.3 Attributes 
5-8.3.1 Class Attributes 


The Base Switch Object shall support the following class attributes. 
Table 5-8.2 Class Attributes 


Attr Need in Access | NV Name Data Description of Semantics of 
ID Implem Rule Type Attribute Values 
1 Optional Get NV _ | Revision UINT Revision of this The current value 
object assigned to this 
value is 1 


2 thru | These class attributes are optional and are described in Volume 1, Chapter 4. 


An error reading the Class Revision attribute implies this is a revision 1 only implementation. 
5-8.3.2 Instance Attributes 


The Base Switch Object shall support the following Instance attributes. 
Table 5-8.3 Instance Attributes 


Attr Need in Access NV Name Data Type Description of Semantics of 
ID Implem Rule Attribute Values 
1 Required | Get Vv Device Up Time | UDINT Time since device | See section 
was powered up 5-8.3.3.1 
2 Required | Get NV Total port count | UDINT Number of Number of physical 
physical ports available ports 
3 Required Get NV System SHORT_S | Human readable Vendor defined 
Firmware TRING representation of ASCII characters. 
Version System Firmware | Maximum length is 
Version 32 characters. 
A length of 0 shall 
indicate no System 
Firmware Version is 
configured. 
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Attr Need in Access NV Name Data Type Description of Semantics of 
ID Implem Rule Attribute Values 
4 Required Get Vv Power Source WORD Status of switch See section 
power source 5-8.3.3.2 
5 Required Get v Port Mask Size UINT Number of Minimum = 4, 
DWORDs in port | supporting 128 
array attributes ports 
6 Optional Get v Existing Ports ARRAY Port Mask Size of array = 
OF attribute 5 
DWORD See section 
5-8.3.3.3 
7 Optional Get, v Global Port ARRAY Ports Admin Size of array = 
Set Admin State OF Status attribute 5 
(option DWORD See section 
al) 5-8.3.3.4 
8 Required Get Vv Global Port Link | ARRAY Ports Link Status | Size of array = 
Status OF attribute 5 
DWORD See section 
5-8.3.3.5 
9 Optional Get NV System Boot SHORT_S | Human readable Vendor defined 
Loader Version | TRING representation of | ASCII characters. 
System Firmware | Maximum length is 
Version 32 characters. 
A length of 0 shall 
indicate no System 
Firmware Version is 
configured. 
10 Optional Get Vv Contact Status WORD Switch Contact See section 
Closure 5-8.3.3.6 
I Optional Get v Aging Time UDINT The timeout Range = 
period in seconds |} 10..1000000; 
for aging out 0 = Learning off; 
dynamically- Default = 300; 
ae (Reference: 
forwarding Ts 
saformalion, on dTpAgingTime, 
in 802.1D 2004) 
12 Optional Get Vv Temperature C DINT Temperature in Switch temperature 
de; C. Only | in degrees Celsius 
available on 
devices that 
support 
temperature 
13 Optional Get Vv Temperature F DINT Temperature in Switch temperature 
degrees F. Only in degrees 
available on Fahrenheit 
devices that 
support 
temperature 
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Attr Need in Access NV Name Data Type Description of Semantics of 
ID Implem Rule Attribute Values 
14 Optional Get Nv! Resiliency STRUCT List of Resiliency | See section 5- 

Protocol List of Protocol entities 8.3.3.7 
used in switch 
Resiliency { UINT Number of Default value = 0 
Protocol Count Resiliency 
Protocol entities 
used in switch 
(i.e.: number of 
entities in the 
array) 
ARRAY of 
Resiliency { STRUCT | Structure with 
Protocol Entity of information on a 
particular 
Resiliency 
Protocol 
Resiliency { UINT Identify which See section 
Protocol Resiliency 5-8.3.3.7.1 
Select protocol is used 
Resiliency ARRAY of | Port Mask Size of array = 
Ports DWORD attribute 5 
See section 
5-8.3.3.7.2 
Resiliency STRUCT Path to instance See section 
Protocol of of a Resiliency 5-8.3.3.73 
Object Protocol object 
{ UINT Path Size Number of 16 bit 
words in Path 
Padded Path: Logical The path is 
EPATH segments restricted to one 
Wy identifying a logical instance 


Resiliency 
Protocol object 


segment. The 
maximum size is 12 
bytes. See Volume 
1, Appendix C, 
Logical Segments. 


Table Footnotes 


1; 


Value may be computed at power up 


5-8.3.3 


5-8.3.3.1 


5-8.3.3.2 


Semantics 


Device Up Time — Attribute 1 


The Device Up Time attribute is the sysUpTime managed object from SNMP MIB System 
Group defined in RFC1213. The sysUpTime is defined as a TimeTick (RFC1155) which is 
represented as a 32 bit unsigned integer with a resolution of hundredth of a second. The 
TimeTick will roll over when the maximum value is reached. 


Power Source - Attribute 4 


The Power Source attribute is a bitmap that shall indicate the status of one or more of the 
switch’s power source or supplies. 
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Table 5-8.4 Power Source Attribute 


Bit(s): Called: Definition: 


0-1 Power Source |__| State of the 00 = Not Present 
Power Source 


(power source not present in switch) 
O1 = Not Powered 

(power source present but not powered) 
10 = Faulted(internal) 

(power source present but faulted) 
11 = Powered and ok 

(power source present, powered, and OK) 


2-3 Power Source 2. | Same as bits 0-1 
4-5 Power Source 3. | Same as bits 0-1 
6-7 Power Source 4 | Same as bits 0-1 
8-9 Power Source 5 Same as bits 0-1 
10-11 Power Source 6 | Same as bits 0-1 


12-13 Power Source 7 | Sameas bits 0-1 


14-15 Power Source 8 | Same as bits 0-1 


5-8.3.3.3 Existing Ports - Attribute 6 


The Existing Ports attribute is a bitmap that shall indicate which ports exist in the Switch 
housing. This attribute is essential to modular switches. 


The bit number within the array of DWORDs corresponds to the associated instance +1 of the 
Ethernet Link Object. 
Table 5-8.5 Existing Ports Attribute 
DWORD(s): Bit(s): Called: Definition: 
0 0 Port 0 Indicates whether | 0 = Absent 
Presence | a Port is Absent (the port is not present in the switch) 
or Presence = 
within the switch 1s Present 2 . , 
(the port is present in the switch) 
Default = 0 
1-31 Same as Bit 0 for ports 1 through 31. 


1 Same as DWORD 0 for ports 32 through 63 


Port Mask Same as DWORD 0 for ports (N-1) x 32) through (N x 32) - 1 
Size (N) - 1 


5-8.3.3.4 Global Port Admin State - Attribute 7 


The Global Port Admin State attribute is a bitmap that consolidates and translates the Admin 
state (attribute 9) of all existing port’s associated Ethernet Link Object instances. 


The bit number within the array of DWORDs corresponds to the associated instance +1 of the 
Ethernet Link Object. 
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Table 5-8.6 Global Port Admin State Attribute 


DWORD(s): Bit(s): Called: Definition: 
0 0 Port 0 Admin Represents a 0 = Port (or Interface) Disabled 
state compressed value 1 = Port (or Interface) Enabled 
of the Admin State Default = 0 (for non-existent ports) 


1-31 Same as Bit 0 for ports | through 31. 
1 Same as DWORD 0 for ports 32 through 63 


Port Mask | Same as DWORD 0 for ports (N-1) x 32 through (N x 32) - | 
Size (N) -1 


5-8.3.3.5 Global Link Status - Attribute 8 


The Global Link Status attribute is a bitmap that consolidates the Link status (attribute 1, bit 0) 
of each existing ports associated Ethernet Link Object instance. 


The bit number within the array of DWORDs corresponds to the associated instance +1 of the 
Ethernet Link Object. 


Table 5-8.7 Global Link Status Attribute 


DWORD(s): Bit(s): Called: Definition: 
0 0 Port 0 Link Represents a 0 = Link inactive (Down) 
status compressed value 1 = Link Active (Up) 
of the Admin State | Default = 0 (for non-existent ports) 


131 Same as Bit 0 for ports 1 through 31. 
1 Same as DWORD 0 for ports 32 through 63 


Port Mask Same as DWORD 0 for ports (N-1) x 32 through (N x 32) - 1 
Size (N) -1 


5-8.3.3.6 Contact Status — Attribute 10 


The Contact Status attribute is a bitmap that shall indicate the closure status of any switch 
contacts that may be present. 


Table 5-8.8 Switch Contact Attribute 


Bit(s): Called: Definition: 
0-1 Switch Contact |__| State of the Switch Contact 00 = Switch Contact not supported/present 
01 = Switch Contact is OPEN 
10 = Switch Contact is CLOSED 
11 = Reserved 


2-3 Switch Contact 2. | Same as bits 0-1. 
4-5 Switch Contact 3. | Same as bits 0-1. 
6-7 Switch Contact 4 | Same as bits 0-1. 
8-15 Reserved 
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Base Switch Object, Class Code: 51 Hex 
Resiliency Protocol List — Attribute 14 


Resiliency Protocol Select 
The Resiliency Protocol Select member identifies which resiliency protocol is used 


Table 5-8.9 Resiliency Protocol Select Values 


Value Description 
0x0000 None 
0x0001 Device Level Ring (DLR) 
0x0002 Rapid Spanning Tree Protocol (RSTP) 
0x0003 Parallel Redundancy Protocol (PRP) 
0x0004-Ox7FFF | Reserved for future use 
Ox8000-OxFFFF | Vendor Specific 


Resiliency Ports 


The Resiliency Ports member is a bitmap that shall indicate which ports are used by the 
selected resiliency protocol. 


Table 5-8.10 Resiliency Ports 


DWORD(s): Bit(s): Called: Definition: 
0 0 Port 0 Indicates whether a Port is Selected | 0 = Not Selected 
Selected for a Particular Resiliency Protocol 1 = Selected 
Default = 0 
1-31 Same as Bit 0 for ports 1 through 31. 


1 Same as DWORD 0 for ports 32 through 63 


Port Mask Same as DWORD 0 for ports (N-1) x 32) through (N x 32) - 1 
Size (N) - I 


Resiliency Protocol Object 


This member identifies the instance of a Resiliency Protocol object. There are two components 
to the attribute: a Path Size (in UINTs) and a Path. The Path shall contain a Logical Segment, 
type Class, and a Logical Segment, type Instance that identifies the resiliency protocol object. 
The maximum Path Size is 6 (assuming a 32 bit logical segment for each of the class and 
instance). 


For example, the path could be as follows: 
Table 5-8.11 Example Path 


Path Meaning 


[20] [56] [24] [01] [20] = 8 bit class segment type; [56] = PRP Object class; [24] = 8 bit 
instance segment type; [01] = instance 1. 
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5-8.4 Common Services 
5-8.4.1 All Services 
The Base Switch Object shall provide the following common services. 
Table 5-8.12 Common Services 
Service Need in Implementation Service Name Description of Service 
Cui Class Instance 
(Hex) 
0x01 Optional Optional Get_Attributes_All Returns multiple attributes in 
numerical order. 
Ox0E Optional Required Get_Attribute_Single | Returns a single attribute 
0x10 Optional Conditional ' Set_Attribute_Single | Sets a single attribute 
Table Footnotes 
1__Required if the device implements Set access to Attribute 7 
5-8.4.2 Get_Attributes_All Response 


The Base Switch Object shall provide the following common services. 


Table 5-8.13 Get_Attributes_All Response 


Attribute Data Type Attribute Name Default Value 
ID (if not implemented) 
1 UDINT Device Up Time 
2. UDINT Total port count 
3 SHORT_STRING System Firmware Version 
4 WORD Power Source 
5 UINT Port Mask Size 
6 ARRAY (Port Mask Size) of Existing Ports. 0 
DWORD 
- ARRAY(Port Mask Size) of Global Port Admin State 0 
DWORD 
8 ARRAY (Port Mask Size) of Global Port Link Status 
DWORD 
9 SHORT_STRING System Boot Loader Version 0, NULL 
10 WORD Contact Status 0 
11 UDINT Aging Time 0 
12 DINT Temperature C 0 
13 DINT Temperature F 0 
14 STRUCT of { Resiliency Protocol List 
UINT Resiliency Protocol Count 0 
ARRAY of { 
STRUCT of { Resiliency Protocol Entity 
UINT Resiliency Protocol Select 
ARRAY of DWORD Resiliency Ports 
STRUCT of { Resiliency Protocol Object 
UINT Path Size 
Padded EPATH }}}} Path 
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Simple Network Management (SNMP) Object 
Class Code: 52 Hex 


Scope 


The SNMP Object provides parameters used to configure aspects of the SNMP Agent in the 
device. 


Configuration of the SNMP capability will include the following activities: 


Indicating whether an SNMP Agent is active. 

Indicating which SNMP Agent version(s) is(are) supported by the target device. 
Enabling SNMP Notifications. 

e Assigning Primary and Secondary Network Manager IP Addresses. 


e If Notifications are enabled, indicating the type of SNMP Trap PDU that the target device 
will use for Notifications, i.e. TrapV1Pdu or TrapV2Pdu. 


If a CIP device implements an SNMP Object, the SNMP requirements and recommendations of 
Appendix G shall also apply to this device. 


If a CIP device implements an SNMP Object, then a CIP device shall implement exactly one 
instance of the SNMP Object. 


Revision History 


Table 5-9.1 Simple Network Management Object Revision History 


Revision Reason for Object Definition Update 


1 Initial revision of this object definition 


Attributes 
Class Attributes 
Table 5-9.2 Simple Network Management Object Class Attributes 


Attr 
ID 


Need in 
Implem 


Access 
Rule 


NV 


Name 


Data 
Type 


Description of 
Attribute 


Semantics of Values 


1 


Optional 


Get 


NV 


Revision 


UINT 


Revision of this 
object 


The current value 
assigned to this value 
is 1 


wv 


These class attributes are optional and are described in Volume 1, Chapter 4. 
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5-9,3.2 Instance Attributes 


Simple Network Management Object, Class Code: 52 Hex 


The SNMP object shall support the following instance attributes. 


Table 5-9.3 Simple Network Management Object Instance Attributes 


Attr Need in Access | NV Name Data Description of Semantics of Values 
ID Implem Rule Type Attribute 
1 Required See NV_ | SnmpAgent USINT | Enables/Disables 1 = Enable (default) 
Note 1 SNMP Agent 0 = Disable 
See section 5-9.3.2.1 
2 Required Get NV _ | SnmpAgentVersion | USINT Version of 1 =SNMPv1 
provided SNMP. 3 = SNMPv3 
Agent 31 = bilingual 
SNMPv1+v3 
All others reserved. 
See section 5-9.3.2.2 
Ss Required See NV | PrimaryNetworkMa | STRUCT | Network address See section 5-9.3.2.3 
Note | nagmentldentifier of of Primary 
Network Manager 
Identifier Format USINT Type of Identifier Default = 0, 
unconfigured 
See semantics 
Identifier STRING | Value of Identifier | Default =“ The 
default value, a null 
string, indicates 
unconfigured. 
4 Required See NV_ | SecondaryNetwork STRUCT | Network address See section 5-9.3.2.4 
Note | Managerldentifier of of Secondary 
Network Manager 
Identifier Format USINT Type of Identifier Default = 0, 
unconfigured 
See semantics 
Identifier STRING | Value of Identifier | Default = “’ The 
default value, a null 
string, indicates 
unconfigured. 
5 Required See NV | Notifications BOOL Indicates if the 1 = Enabled (default) 
Note | SNMP Agent will |g = Disabled 
enable ne sending See section 5-9.3.2.5 
of notifications 
6 Optional See NV | TrapType USINT Indicated which 1 = TrapV1Pdu 
Note | Trap Type the — 2 = TrapV2Pdu (shall 
SNMP Agent will | only be allowed if 
send SnmpAgentVersion = 
3 or 31) 
All others reserved. 
See section 5-9.3.2.6 
Note I: “Set” is optional and “Get” is required. If “Set” is not provided, then a vendor specific configuration means shall 
be provided. 
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5-9.3.2.1 


5-9,.3.2.2 


5-9.3.2.3 


5-9.3.2.4 


5-9.3.2.5 


Simple Network Management Object, Class Code: 52 Hex 


SnmpA gent - Attribute 1 
The SnmpAgent attribute enables or disables the SNMP Agent. 
The default value of SnmpAgent shall be 1. 
The Set_Attribute_Single service for this attribute is optional. 
Tf the Set_Attribute_Single service is implemented for this attribute, then the new value of 
SnmpA gent shall take effect immediately. 
SnmpAgentVersion — Attribute 2 


The SnmpAgentVersion attribute indicates which version(s) of the SNMP Agent is(are) 
provided. 


A value of 1 for SnmpAgentVersion shall indicate an SNMPv1 Agent. 
A value of 3 for SnmpAgentVersion shall indicate an SNMPv3 Agent. 


A value of 31 for SnmpAgentVersion shall indicate that the EtherNet/IP device provides a bi- 
lingual SNMP Agent composed of SNMPv1 and SNMPv3. If a device provides a bilingual 
agent, then it shall be the responsibility of the device to manage MIB access in such a way that 
restricted MIBs that are only accessible using V3 with security features are not accessible to V1 
requests. 


PrimaryNetworkManagerldentifier — Attribute 3 


The PrimaryNetworkManagerldentifier attribute identifies the Primary Network Manager to 
which TrapPdus shall be sent. 


A value of 0 for the IdentifierFormat and a value of *’, the null string, for the Identifier shall 
indicate that the PrimaryNetworkManagerldentifier has not been configured. 


The following values of Identifier Format are defined: 


e If Identifier Format = 0, then the attribute is unconfigured. 
e If Identifier Format = 1, then the Identifier shall provide an IPv4 address. The IPv4 address 
shall have the ‘dotted decimal notation’ format, e.g. ‘123.123.123.123’. 


e If Identifier Format = 2, then the Identifier SHALL provide a Domain Name. The Domain 
Name shall be compliant with IETF RFC 1034 and specifically its clause 3.5. 


All other Identifier Format values are reserved. 


SecondaryNetworkManagerldentifier — Attribute 4 


The SecondaryNetworkManagerldentifier attribute identifies the Secondary Network Manager 
to which TrapPdus shall be sent. 


A value of 0 for the IdentifierFormat and a value of *’, the null string, for the Identifier shall 
indicate that the SecondaryNetworkManagerldentifier has not been configured. 


The currently defined values for IdentifierFormat are show in section 5-9.3.2.3 


Notifications — Attribute 5 


The Notifications attribute shall indicate whether the sending of SNMP TrapPdus by the SNMP 
Agent is enabled or disabled. 
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The default value of Notifications shall be 1 indicating that the sending of SNMP TrapPdus by 
the SNMP Agent is enabled. 
5-9,3.2.6 TrapType — Attribute 6 
The TrapType attribute shall indicate the type of SNMP TrapPdu that the agent will send. 
A value of | for TrapType shall indicate that the SNMP Agent will send TrapV | Pdus. 
A value of 2 for TrapType shall indicate that the SNMP Agent will send TrapV2Pdus. 
A value of 2 for TrapType shall only be allowed if SnmpAgentVersion = 3 or 31. 


If SnmpAgentVersion = | and a SetAttribute request is received to Set TrapType to 2, then a 
General Status Code (0x09) shall be returned. 


5-9.4 Common Services 
The SNMP Object shall provide the following common services. 
Table 5-9.4 Simple Network Management Object Common Services 


i Need in Implementation 
sizalae Service Name Description of Service 

Code Class Instance 
0x01 Optional Optional Get_Attributes_All See Volume 1, Appendix A. 


Ox0E Conditional ! Required Get_Attribute_Single | See Volume 1, Appendix A 


0x10 n/a Required Set_Attribute_Single | See Volume 1, Appendix A 


Table Footnotes 
1 The Get_Attribut_Single service shall be implemented if any class attribute is 
implemented. 


5-9.4.1 Get_Attributes_All Response 


5-9.4.1.1 Class Level 


At the class level, the Get_Attributes_All response SHALL contain the class attributes in 
numerical order, up to the last implemented attribute. Any unimplemented attributes in the 
response SHALL use the default attribute values. 


5-9.4.1.2 Instance Level 


For instance attributes, attributes shall be returned in numerical order up to the last 
implemented attribute. The Get_Attributes_All reply shall be as follows: 


Table 5-9.5 Get_Attributes_All Response 


Attribute Size [bytes] Content 
1 1 | SnmpAgent 
2 1 | SnmpAgentVersion 
3 3 + LengthOfString | PrimaryNetworkManagerldentifier 
4 3 + LengthOfString SecondaryNetworkManagerldentifier 
3 1 | Notifications 
6 1 | TrapType 
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5-10 


5-10.1 


5-10.2 


5-10.3 


5-10.4 


5-10.5 
5-10.5.1 


5-10.5.2 


5-10.5.3 


Power Management Object, Class Code: 53 Hex 


Power Management Object 
Class Code: 53 Hex 
Scope 


This section defines EtherNet/IP adaptation requirements for implementing optional behavior 
of the Power Management Object defined in Volume 1. This section does not define a complete 
standalone object. 


The Power Management Object defines a Sleeping state and a Paused state. The method to 
trigger the transition from the Sleeping state to the Paused state is adaptation-specific. 


This adaptation adopts the Wake-on-LAN (“WoL”) mechanism documented in an AMD 
whitepaper, Publication 20213, Rev: A, Amendment 0, Issue Date: November 1995. 


The transition is triggered by receipt of an Ethernet frame containing a special payload known 
as the Magic Packet™. 


Revision History 

This adaptation defines no independent Revision History. 
Attributes 

This adaptation defines no Attributes. 

Services 

This adaptation defines no Services. 

Behavior 

General 


EtherNet/IP devices that include a Power Management Object implementation that supports the 
Sleeping state (as indicated by Attribute #6 = 1) shall incorporate WoL capable Ethernet 
hardware and support the WoL protocol defined in this section. 


The Power Management Object defines the Sleeping state which is expected to be a low power 
state. The actual power level within this state is implementation-specific and beyond the scope 
of this standard. 


The Sleeping state 


During the Sleeping state the application processor and most of the communication hardware 
may be shut down. The CIP application stack and the TCP/IP stack will not be available to 
provide service. Only the Ethernet MAC and PHY hardware remain active in a minimal receive 
mode to wake the device in response to receipt of the Magic Packet. This represents the lowest 
power state from which a device can be recovered to an operational state via network 
communication. 


Entry into the Sleeping state 
The WoL specification does not define the method for entry into the low power state. 


The method for entry into the Sleeping state is described in Volume 1. 
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5-10.5.5 


5-10.5.6 


5-10.5.7 


Power Management Object, Class Code: 53 Hex 


Exit from the Sleeping state 


The WoL specification defines the method for exit from the low power state. During the low 
power state, compliant Ethernet MAC hardware processes the payload (data portion) of 
received frames. A special frame known as the Magic Packet contains a device-specific 
payload. When the MAC hardware receives a Magic Packet with a MAC address matching its 
own, a device-specific wakeup sequence is initiated. 


An EtherNet/IP device implementing a Power Management Object that includes the Sleeping 
state shall exit the Sleeping state and transition to the Paused state upon receipt of a Magic 
Packet addressed to the device. 

Non-Sleeping states 


A device that is not in a Sleeping state shall not change its Power Management Object state in 
response to a Magic Packet. 


Magic Packet Definition 
The format of the Magic Packet shall comply with the AMD whitepaper. 


The format is described here for informative purposes. The Magic Packet payload contains 6 
bytes of 255 (OxFF OxFF OxFF OxFF OxFF OxFF), followed by sixteen repetitions of a device’s 
48-bit MAC address, for a total of 102 bytes. According to the WoL specification, this data 
pattern may be anywhere in the payload. It is recommended that the data pattern be placed at 
offset = 0 in the payload as illustrated in the following example: 


For MAC address 00-1c-23-a6-c9-98 we have: 


00 01... - 101 
FF FF FF FF FF FF 00 IC 23 A6 C9 98 ... 00 1C 23 A6 C9 98 


The Magic Packet may be encapsulated in any Ethernet frame. The choice of encapsulation is 
beyond the scope of this specification. 


Recommended Client Behavior 


Because Magic Packets are not acknowledged and therefore inherently unreliable, the client has 
no direct method to determine their receipt by the server. The server will remain in the Sleeping 
state if the Magic Packet is lost or corrupted. 


It is recommended that the client repeat the Magic packet three times at a 100ms interval. 
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5-11 RSTP Bridge Object 
Class Code: 54 Hex 
5-11.1 Scope 


The RSTP Bridge Object provides the configuration and diagnostic interface for the RSTP 
protocol at the bridge level. The RSTP protocol is a layer 2 protocol that enables the use of an 
Ethernet ring topology. The RSTP protocol is fully specified in Chapter 17 of IEEE 802.1D- 
2004 and also described in Chapter 9 of this document. The RSTP Bridge Object provides the 
CIP application-level interface to the protocol at bridge scope. 


The RSTP Bridge Object should be implemented in all Managed Ethernet Switch Devices 
(Device Type: 0x2C ) that support RSTP protocol. 


Devices may support multiple instances of RSTP Bridge Objects ( e.g.: Multiple VLANs). 
5-11.2 Revision History 
Table 5-11.1 Revision History 


Revision Reasaon for Object Definition Update 


1 Initial revision of this object class 


5-11.3 Attributes 


5-11.3.1 Class Attributes 
Table 5-11.2 Class Attributes for RSTP Bridge Object 


Attribute Need in Access | NV Name Data Type | Description of Semantics of 
ID Implementation Rule Attribute Values 
1 Optional Get NV_ | Revision UINT Revision of The current value 
this object assigned to this 
value is 1 
2 thru7 These class attributes are optional and are described in Volume 1, Chapter 4. 
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5-11.3.2 Instance Attributes 


The RSTP Bridge Object shall support the following instance attributes. For more information 
on these attributes, refer to Section 14.8.1 of IEEE 802.1D-2004. 


Table 5-11.3 Instance Attributes for RSTP Bridge Object 


Attribute Need in Access | NV Name Data Description of Semantics of 
ID Implementation Rule Type Attribute Values 
1 Required Get NV | Bridge SHORT__ | Identification for Vendor defined 
Set is Object STRING | each Bridge Object. ASCII characters. 
optional Identificatio Maximum length 
n is 32 characters. 
A length of 0 
shall indicate no 
Bridge 
Identification 
used. 
2 Required Get NV _ | Bridge UINT The manageable Range: 0-61440 
Set is Identifier component of the in steps of 4096 
optional Priority Bridge Identifier, Default = 32768 


also known as the 
Bridge Priority 
Refer to IEEE 


802.1D -2004, 
§17.13.7 
3 Required Get NV_ | Transmit UINT The Transmit Hold Range: | to 10 
Set is Hold Count Count used by the counts 
optional Port Transmit state Default = 6 


machine to limit 
transmission rate 
Refer to IEEE 


802.1D -2004, 
§17.13.12 
4 Required Get Vv Number of UINT Number of RSTP Number = 2, 3, .., 
RSTP Ports ports associated with | N 
this bridge Default = 2 
5 Required Get Vv List of RSTP | Array of List of instance Range: | to 
Port Object UINT numbers of the 65535 
References associated RSTP port | Default = 1 
hits For each instance 
number. 
6 Optional Get NV | Force UINT The Force Protocol O= STP 
Set is Protocol Version parameter Compatibility 
optional Version for the Bridge mode 
Refer to IEEE 2 = Normal 
802.1D -2004, Operation 
§17.13.4 (default). 
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Attribute Need in Access | NV Name Data Description of Semantics of 
ID Implementation Rule Type Attribute Values 
af: Optional Get NV _ | Bridge Max | UINT The maximum age of | Range: 6.0 to 
Set is Age the information 40.0 seconds 
optional transmitted by the Default = 20.0 
Bridge when it is the} seconds 
Root Bridge Resolution: 1/256 
Refer to IEEE praacecnd 
802.1D -2004, 
§17.13.8 
8 Optional Get NV _ | Bridge Hello | UINT The interval between | Range: 1.0 to 2.0 
Set is Time periodic seconds 
optional transmissions of Default = 2.0 
Configuration seconds 
Messages by Resolution: 1/256 
Designated Ports ofa second 
Refer to IEEE 
802.1D -2004, 
§14.8.1 
9 Optional Get NV | Bridge UINT The delay used by Range: 4.0 to 
Set is Forward STP Bridges to 30.0 seconds 
optional Delay transition Root and Default = 15.0 
Designated Ports to seconds 
Forwarding Resolution: 1/256 
Refer to IEEE of a second 
802.1D -2004, 
§17.18.4 
10 Optional Get Vv Time Since UDINT The Topology Range: 0 to 
Topology Change timer. TCN | 16,777,215.0 
Change Messages are sent seconds 
while this timer is Default = 0 
running seconds 
Refer to IEEE Resolution: 1/256 
802.1D -2004, of a second 
§14.8.1 
11 Optional Get Vv Topology UDINT The total number of Range: 0 to 
Change topology changes 4,294,967,295 
Count detected by this counts 
bridge since the Default = 0 
management entity counts 
was last reset or 
initialized 
Refer to IEEE 
802.1D -2004, 
§14.8.1. 
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Attribute Need in Access | NV Name Data Description of Semantics of 
ID Implementation Rule Type Attribute Values 
12 Optional Get Vv Designated Array of The bridge identifier | Combination of 
Root USINT of the root of the two byte bridge 
spanning priority and 6 
tree. This value is byte bridge base 
used as the Root MAC address 
Identifier parameter Default = 0 
in all Configuration 
Bridge PDUs 
originated by this 
node. 
Refer to IEEE 
802.1D -2004, 
§17.18.6 
13 Optional Get v Root Cost UDINT The cost of the path Range: 1 - 
to the root as seen 200,000,000 
from this bridge. Default = 
Refer to IEEE 200,000 for 
802.1D -2004, 100Mbps 
§17.18.6 
14 Optional Get Vv Root Port UINT The port identifier of | Range: | to 
the port that offers 65535 
the lowest cost path Default = 0 
from this bridge to (Undefined) 
the root bridge. 
Refer to IEEE 
802.1D -2004, 
§17.18.6 
15 Optional Get Vv Max Age UINT The maximum age of | Range: 6.0 to 
Spanning Tree 40.0 seconds 
Protocol information | Default = 20.0 
Cue naa oan Resolution: 1/256 
f a second 
before it is discarded, tere 
This is the actual 
value that this bridge 
is currently using. 
Refer to IEEE 
802.1D -2004, 
§17.18.7 
16 Optional Get Vv Hello Time UINT The amount of time Range: 1.0 to 2.0 
between the seconds 
transmission of Default = 2.0 
Configuration bridge | seconds 
PDUs by this node on | Resolution: 1/256 
any port when it is ‘of a necond 
the root of the 
spanning tree, or 
trying to become so, 
this is the actual 
value that this bridge 
is currently using. 
Refer to IEEE 
802.1D -2004, 
§17.13.6 
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Attribute Need in Access | NV Name Data Description of Semantics of 
ID Implementation Rule Type Attribute Values 
17 Optional Get Vv Forward UINT This time value Range: 4.0 to 30 
Delay controls how fast a second: 
port changes its Default = 15.0 
spanning state when seconds 
moving towards the | Resolution: 1/256 
Forwarding state. ofasecond 
This value is the one 
that this bridge is 
currently using, in 
contrast to 
BridgeForwardDelay, 
which is the value 
that this 
bridge and all others 
would start using 
if/when this bridge 
were to become the 
root 
Refer to IEEE 
802.1D -2004, 
§17.13.5 
5-11.4 Common Services 
The RSTP Bridge Object shall provide the following common services. 
Table 5-11.4 RSTP Bridge Object Common Services 
Service Need in Implementation 
Code Class Instance Service name Description of Service 
Ox01 Optional Optional Get_Attributes_All Returns multiple attributes in numerical order 
Ox0E Optional Required Get_Attribute_Single | Returns a single attribute 
0x10 wa Conditional | Set_Attribute_Single | Modifies a single attribute 
The Get_Attribute_Single SHALL be implemented for the class attribute if any class attribute 
is implemented. 
The Set_Attribute_Single SHALL be implemented for the instance attribute if any instance 
attribute is implemented and settable. 
5-11.5 Get_Attributes_All Response 
5-11.5.1 Class Level 


At the class level, the Get_Attributes_All response shall contain the class attributes in 
numerical order, up to the last implemented attribute. Any unimplemented attributes in the 
response SHALL use the default attribute values. 


— 5-76 - 
Edition 1.18 


SINGLE SUBSCRIPTION ONLY; SUBSCRIPTION TERMS AND CONDITIONS OUTLINED ON PAGE (iii) 


Volume 2: EtherNet/IP Adaptation of CIP, Chapter 5: Object Library 


RSTP Bridge Object, Class Code: 54 Hex 


5-11.5.2 Instance Level 
At the instance level the Get_Attributes_All response shall be as follows. 
Table 5-11.5 Get_Attributes_All Response 
Attribute Size in Bytes Contents 

ID 

1 1 Bridge Object Identification Length 
Variable, equal to Bridge Object | Bridge Object Identification 
Identification Length 

2 2 Bridge Identifier Priority 

3 2 Transmit Hold Count 

4 2 Number of RSTP Ports 

5 Variable, equal to 2 for each of | The RSTP Port Object Instances for each of the ports listed in the line above. 
the RSTP Ports (Attribute 4) 

6 2 Force Protocol Version - 2 if not implemented 

7: 2 Bridge Max Age — 0 if not implemented 

8 2 Bridge Hello Time — 0 if not implemented 

9 2 Bridge Forward Delay — 0 if not implemented 

10 4 Time Since Topology Change — 0 if not implemented 

ll 4 Topology Change Count — 0 if not implemented 

12 8 Designated Root — 0 if not implemented 

13 4 Root Cost — 0 if not implemented 

14 2 Root Port — 0 if not implemented 

15 2 Max Age — 0 if not implemented 

16 2 Hello Time — 0 if not implemented 

17 2 Forward Delay — 0 if not implemented 
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5-12 RSTP Port Object 
Class Code: 55 Hex 
5-12.1 Scope 
The RSTP Port Object provides a configuration and diagnostic interface for the RSTP protocol 
at the port level. 
The RSTP Port Object shall be implemented in all Managed Ethernet Switch Devices (Device 
Type: 0x2C) that support RSTP Bridge Object. 
Devices supporting RSTP Bridge Object shall implement at least 2 instances of the RSTP Port 
Object. All Ethernet ports supporting RSTP Port Object shall be associated with a RSTP 
Bridge Object, defined in section 5-11 of this document. 
§-12.2 Revision History 
Table 5-12.1 Revision History 
Revision Reason for Object Definition Update 
1 Initial revision of this object definition 
5-12.3 Attributes 
5-12.3.1 Class Attributes 
The RSTP Port Object shall support the following class attributes. 
Table 5-12.2 Class Attributes 
Attribute Need in Access | NV Name Data Description of Semantics of Values 
ID Implementation Rule Type Attribute 
if Optional Get Vv Revision UINT Revision of this object | The value SHALL be 
1 
2 Required Get Vs} Max UINT Maximum instance The largest instance 
Instance number of an object number of a created 
currently created in object at this class 
this class level of the hierarchy level 
device 
3 Required Get Vv Number UINT Number of object The number of object 
of instances currently instances at this class 
Instance created at this class hierarchy level 
level of the device 
4thru7 | These class attributes are optional and are described in Volume |, Chapter 4 of the CIP Networks Library 
5-12.3.2 Instance Attributes 
The RSTP Port Object shall support the following instance attributes. For more information on 


these attributes, refer to Section 17 of IEEE 802.1D-2004. 
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Table 5-12.3 Instance Attributes 


Attribute Need in Access NV Name Data Description of Semantics of Values 
ID Implem Rule Type Attribute 
1 Required Get V_ | Bridge Object. | UINT Bridge Object Range: | to 65535 
Instance Instance number Default = 1 
associated with this 
RSTP Port Object 
2. Required Get Vv Ethernet Link UINT Indicates the Range: 0 to 65535 
Instance Ethernet link object | Default = 0 
Number instance associated 
with this RSTP port 
object. 
3 Required Get Vv Reference ARRAY Identifier of the Combination of two 
Bridge of 8 bridge with which | byte bridge priority 
Identifier USINTs this port associated and 6 byte bridge 
base MAC address 
4 Required Get NV _ | Port MAC ARRAY Unique MAC MAC address 
Address of 6 Address of the port 
USINTs instance in attribute 
2. 
5 Required Get NV _ | RSTP Port BOOL The 0 =RSTP Disabled 
Set Enable enabled/disabled (default) 
status of the port. 1 = RSTP Enabled 
6 Required Get NV | Port Identifier | UDINT The manageable Range: 0-240 in 
Set is Priority component of the steps of 16 
optional Port Identifier, also | Default = 128 
known as the Port 
Priority 
Refer to IEEE 
802.1D -2004, 
§17.19.21 
i Required Get Vv Oper Edge Port | BOOL A boolean. The 1 = True (default) 
value of the 0 = False 
operEdgePort 
parameter, as 
determined by the 
operation of the 
Bridge Detection 
state machine 
Refer to IEEE 
802.1D -2004, 
§17.19.17 
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Attribute 
ID 


Need in 
Implem 


Access 
Rule 


NV 


Name 


Data 
Type 


Description of 
Attribute 


Semantics of Values 


8 


Required 


Get 


v 


Port State 


UINT 


The port's current 
state, as defined by 
application of the 
Spanning Tree 
Protocol. 

Refer to IEEE 
802.1D -2004, 
§17.29 

The Disabled Port 
state is assigned if 
the port is not 
operational or is 
excluded from the 
active topology. 
These states are set 
by the RSTP state 
machine and are not 
settable. 


1 = Disabled 

2 = Blocking 

3 = Listening 

4 =Leaming 

5 = Forwarding 
6 = Broken 
Default = 1 


9 


Optional 


Get 
Set is 
optional 


NV 


mcheck 


BOOL 


A boolean. May be 
set by management 
to force the Port 
Protocol Migration 
state machine to 
transmit RST 
BPDUs for a 
MigrateTime period 
Refer to IEEE 
802.1D -2004, 
§17.19.13 


1 =True 
0 = False (default) 


Optional 


Get 


Set is 
optional 


NV 


Port Path Cost 


UDINT 


The 
administratively 
assigned value for 
the contribution of 
this port to the path 
cost of paths toward 
the spanning tree 
root 

Refer to IEEE 
802.1D -2004, 
§17.13.11 


Range: 0 to 
200,000,000 
Default: 0 (Writing a 
value of ’0’ assigns 
the automatically 
calculated default 
Path Cost value to 
the port) 


Optional 


Get 
Set is 
optional 


NV 


Port Admin 
Edge Port 


BOOL 


The administrative 
value of the Edge 
Port parameter. A 
value of true 
indicates that this 
port should be 
assumed as an edge- 
port, and a value of 
false indicates 

that this port should 
be assumed as a 
non-edge-port 
Refer to IEEE 
802.1D -2004, 
§17.20.1 


1 =True 
0 = False (default) 
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Attribute 
ID 


Need in 
Implem 


Access 
Rule 


NV 


Name 


Data 
Type 


Description of 
Attribute 


Semantics of Values 


12 


Optional 


Get 


Set is 
optional 


NV 


Admin 
PointToPoint 
MAC 


UINT 


The administrative 
point-to-point status 
of the LAN segment 
attached to this port 
Refer to IEEE 
802.1D -2004, 
§6.4.3 


0 = forceTrue 
1 = forceFalse 
2 = auto (default) 


Optional 


Oper 
PointToPoint 
MAC 


UINT 


The operational 
point-to-point status 
of the LAN segment 
attached to this port 
Refer to IEEE 
802.1D -2004, 
§6.4.3 


1 = True 
0 = False (default) 


Optional 


Port Role 


UINT 


Port Role values 
Refer to IEEE 
802.1D -2004, 
§9.2.9 


0 = Unknown 
(default) 

1 = Alternate/Backup 
2 = Root 

3 = Designated 


Optional 


Get 


Designated 
Root Bridge 
Identifier 


ARRAY 
of 8 
USINTs 


The unique Bridge 
Identifier of the 
Bridge recorded as 
the Root in the 
Configuration 
BPDUs transmitted 
by the Designated 
Bridge for the 
segment to which 
the port is attached. 
Refer to IEEE 
802.1D -2004, 
§17.5 


Combination of two 
byte bridge priority 
and 6 byte bridge 
base MAC address 


Optional 


Get 


Designated 
Root Path Cost 


UDINT 


The path cost of the 
Designated Port of 
the segment 
connected to this 
port. This value is 
compared to the 
Root Path Cost field 
in received bridge 
PDUs. 

Refer to IEEE 
802.1D -2004, 
§17.5 


Range: | — 
200,000,000 
Default: 200,000 


Optional 


Get 


Designated 
Bridge 
Identifier 


ARRAY 
of 8 
USINTs 


The Bridge 
Identifier of the 
bridge that this port 
considers to be the 
Designated Bridge 
for this port's 
segment 

Refer to IEEE 
802.1D -2004, 
§17.5 


Combination of two 
byte bridge priority 
and 6 byte bridge 
base MAC address 
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Attribute Need in Access NV Name Data Description of Semantics of Values 
ID Implem Rule Type Attribute 
18 Optional Get Vv Designated UINT The Port Identifier Range: | to 65,535 
Port of the port on the Default: 0 
Designated Bridge 
for this port's 
segment 
Refer to IEEE 
802.1D -2004, 
817.5 
19 Optional Get Vv Forward UDINT The number of Range: 0 to 
Transitions times this port has 4,294,967,295 
Count transitioned from Default: 0 
the Learning state to 
the Forwarding state 
IETF RFC 4188 
dot] StpPortForward 
Transitions 
5-12.4 Common Services 
The RSTP Port Object shall provide the following common services. 
Table 5-12.4 RSTP Port Object Common Services 
i Need in Implementation 
SERIE B Service Name Description of Service 
Code (Hex) Class Instance 
Ox01 Optional Required Get_Attributes_All Returns multiple attributes in numerical order. 
Ox0E Required Required Get_Autribute_Single Returns a single attribute 
0x10 n/a Conditional ' Set_Attribute_Single Modifies a single attribute 


Table Footnotes 


1 The Set_Attribute_Single shall be implemented for the instance attribute if any instance attribute is implemented and 


settable. 
5-12.5 Get_Attributes_All Response 
5-12.5.1 | Class Level 


At the class level, the Get_Attributes_All response shall contain the class attributes in 
numerical order, up to the last implemented attribute. Any unimplemented attributes in the 
response shall use the default attribute values. 
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5-12.5.2 Instance Level 
At the instance level the Get_Attributes_All response shall be as follows. 


Table 5-12.5 Get_Attributes_All Response 


Attribute ID Size in Bytes Contents 


1 2 Bridge Object Instance 


Port Instance Number 


Reference Bridge Identifier 


Port MAC Address 


Port Identifier Priority 


Port Oper Edge Port 


2 

8 

6 

2 Port Enable 
4 

1 

2 Port State 
1 


wlelrlalufa}wr 


mcheck — 0 if not implemented 


10 4 Port Path Cost — 0 if not implemented 

11 1 Admin Edge Port — 0 if not implemented 

12 2 Admin PointToPoint MAC - 0 if not implemented 
13, 2 Oper PointToPoint MAC — 0 if not implemented 
14 2 Port Role — 0 if not implemented 

15 8 Designated Root — 0 if not implemented 

16 4 Designated Cost — 0 if not implemented 

17 8 Designated Bridge — 0 if not implemented 

18 2 Designated Port — 0 if not implemented 

19 4 Forward Transitions Count — 0 if not implemented 
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5-13 Parallel Redundancy Protocol (PRP) Object 
Class Code: 56 Hex 
5-13.1 Scope 


The Parallel Redundancy Protocol (PRP) Object provides a configuration and diagnostic 
interface. The PRP is an OSI layer 2 protocol that provides high availability through a Dual 
attachment, dual LAN Ethernet topology. PRP is fully specified in Clause 4 of the IEC 62439- 
3 (2012-07) Ed. 2.0 Standard, and also briefly described in Chapter 9 of this document. The 
PRP Object provides the CIP application-level interface to the protocol. 


5-13.2 Revision History 
Table 5-13.1 Revision History 


Revision Reason for Object Definition Update 


1 Initial revision of this object definition 


5-13.3 Attributes 
5-13.3.1 Class Attributes 
Table 5-13.2 Class Attributes 


Attribute Need in Access | NV Name Data Description of Semantics of Values 
ID Implementation Rule Type Attribute 
1 thru7 These class attributes are optional and are described in Volume 1, Chapter 4 


5-13.3.2 Instance Attributes 


The PRP Object shall support the following instance attributes. These instance attributes 
correlate to the MIB object definitions described in clause 7 of the IEC 62439-3 (2012-07) Ed. 
2.0 Standard. 


Table 5-13.3 Instance Attributes 


Attribute Need in Access NV Name Data Type Description of Semantics of Values 
ID Implem Rule Attribute 
1 Required Get NV | PRPEnable | BOOL PRP Enable Flag TRUE indicates that 


PRP is Enabled, 
FALSE indicates that 


PRP is Disabled, 
Default=FALSE 
2 Required Get NV | Node Type UINT Operating Mode of | Default = 1; 
Node See section 
5-13.3.3.1 
3 Required Get NV | Node Name SHORT_S Human readable Vendor defined 
TRING representation of ASCII characters. 
Name of the PRP A length of 0 shall 
Link Redundancy indicate no Node 
Entity Name is configured. 


The string content 
should be the same as 
the MIB Object ID, if 
any is provided. 
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Attribute Need in Access NV Name Data Type Description of Semantics of Values 
ID Implem Rule Attribute 
4 Required Get NV | Version SHORT_S Human readable Vendor defined 
Name TRING representation of ASCII characters. 
version Name of the | Maximum length is 
PRPLink 32 characters. The 
Redundancy Entity | string content should 
be the same as the 
MIB Object ID, if 
any is provided. 
A length of 0 is not 
allowed for this 
attribute. 
5 Required Get NV | PRP MAC ETH_MAC | Specifies the MAC 
Set is Address, _ADDR address to be used 
optional by PRP 
6 Required Get/Set NV | Duplicate UINT Specifies whether doNotDiscard (0), 
Discard the duplicate discard (1); 
discard algorithm is Default = 1 
used at reception. 
The RCT shall 
always be inserted 
by a PRP LRE 
7 Required Get/Set NV | Transparent UINT If 0, the RCT is removeRCT (0), 
Reception removed from the passRCT (1); 
frame by the LRE | Herautt <0: 
before forwarding : 
to the upper layers 
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Attribute Need in Access NV Name Data Type Description of Semantics of Values 
ID Implem Rule Attribute 
8 Required Get V_ | PRP STRUCT See section 

Interface of: 5-13.3.3.2 

Counters 

Transmit UDINT Number of frames 

Count A sent over Port A 
that have a PRP 
Redundancy 
Control Trailer 

Transmit UDINT Number of frames 

Count B sent over Port B that 
have a PRP 
Redundancy 
Control Trailer 

Transmit UDINT Number of frames 

Count C sent over the 
interlink of the 
Redundancy Box or 
to the DANP 
application interface 

Receive UDINT Number of frames. 

Count A received on Port A 
that have a PRP 
Redundancy 
Control Trailer 

Receive UDINT Number of frames 

Count B received on Port B 
that have a PRP 
Redundancy 
Control Trailer 

Receive UDINT Number of frames 

Count C received on the 
interlink of the 
Redundancy Box or 
the DANP 
application interface 

Wrong LAN | UDINT Number of frames 

A Count with the wrong 
LAN identifier 
received on LRE 
Port A. 

Wrong LAN | UDINT Number of frames 

B Count with the wrong 
LAN identifier 
received on LRE 
Port B. 
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Attribute Need in Access NV Name Data Type Description of Semantics of Values 

ID Implem Rule Attribute 

9 Required Get V_ | PRP STRUCT See Section 
Duplicate of: 5-13.3.3.3 
Detection 
Counters 
Entries UDINT Number of Entries 
Unique in the duplicate 
Count A detection 

mechanism on port 
A for which no 
duplicate was 
received. 
Entries UDINT Number of Entries 
Unique in the duplicate 
Count B detection 
mechanism on port 
B for which no 
duplicate was 
received. 
Entries UDINT Number of Entries 
Duplicate in the duplicate 
Count A detection 
mechanism on port 
A for which one 
single duplicate was 
received. 
Entries UDINT Number of Entries 
Duplicate in the duplicate 
Count B detection 
mechanism on port 
B for which one 
single duplicate was 
received. 
Entries UDINT Number of Entries 
Multiple in the duplicate 
Count A detection 
mechanism on port 
A for which more 
than one duplicate 
was received 
Entries UDINT Number of Entries 
Multiple in the duplicate 
Count B detection 
mechanism on port 
B for which more 
than one duplicate 
was received. 

10 Required Get V_ | PRP Proxy UDINT Number of Nodes in 
Nodes the Proxy Nodes 
Count Table 
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Attribute Need in Access NV Name Data Type Description of Semantics of Values 
ID Implem Rule Attribute 
11 Required Get, Get_ Vv Proxy Nodes | ARRAY 
Member(s) Table of: 
Proxy Node | ETH_MAC | Specifies the MAC 
MAC _ADDR, address of the Node 
Address this device acts as a 
proxy for. 
12 Optional Get V_ | PRP Nodes STRUCT Path to PRP Nodes 
Table Path of Table object 
UINT Path Size Number of 16 bit 
words in Path 
Padded Path: Logical The path is restricted 
EPATH segments to one logical 
identifying the instance segment. 
Nodes Table object | The maximum size is 
12 bytes. 
See Volume 1, 
Appendix C, Logical 
Segments. 


5-13.3.3. Semantics 


5-13.3.3.1 Node Type — Attribute 2 
The PRP Node Type attribute identifies the operating mode of the Node. 
Table 5-13.4 Node Type 


Value Node Type 
0 Deprecated (PRP Mode 0) 
1 PRP Mode 1 
2- 65535 Reserved for Future use. 


“Deprecated (PRP Mode 0)” is present for historical reasons. PRP existed in a version 0 
(corresponding to the Ist Edition of IEC 62439). After the first edition was replaced by the 
TEC 62439 Edition 2 standards series, PRP Mode 0 was deprecated and replaced by PRP Mode 
1, the current version. There is a need to distinguish nodes working with version 0 and 1, 
because the sequence number scheme has changed between the two. This results in an 
incompatibility between the two versions. 


5-13.3.3.2 PRP Interface Counters — Attribute 8 
The PRP Interface Counters attribute contains counters specific to the Parallel Redundancy 
Protocol (PRP). These counters shall be as defined by IEC 62439-3 standard. 

5-13.3.3.3 PRP Duplicate Detection Counters - Attribute 9 


The PRP Duplicate Detection Counters attribute contains counters specific to the Parallel 
Redundancy Protocol (PRP). These counters shall be as defined by IEC 62439-3 standard. 


5-13.4 Common Services 


The PRP Object provides the following common services. 
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Table 5-13.5 PRP Object Common Services 


asus Need tn Tplementation Service Name Description of Service 
Code (Hex) Class Instance 
OxOL Optional Optional Get_Attributes_All Returns multiple attributes in numerical order. 
Ox0E Conditional! | Required | Get_Attribute_Single | Returns a single attribute 
Ox10 n/a Required * | Set_Attribute_Single | Modifies a single attribute 
Ox18 na Required | Get_Member? Returns the content of a selected member of an 


attribute 


Table Footnotes 


1 The Get_Attribute_Single shall be implemented for the class attribute if any class attribute is implemented. 


2 The Get_Member service is only required to be implemented for Proxy Nodes Table (Attribute #1 1) 


3 Service is required but a vendor can include mechanism for the user to disable for security reasons 


5-13.5 Get_Attributes_All Response 
5-13.5.1 Class Level 


At the class level, the Get_Attributes_All response shall contain the class attributes in 
numerical order, up to the last implemented attribute. Any unimplemented attributes in the 
response shall use the default attribute values. 
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5-13.5.2 Instance Level 
At the instance level the Get_Attributes_All response shall be as follows. 


Table 5-13.6 Get_Attributes_All Response 


Default Value 
Attribute ID Data Type Attribute Name ifeetieaereaiel) 
1 BOOL PRP Enable 
2 UINT Node Type 
3 SHORT_STRING Node Name 
4 SHORT_STRING Version Name 
5 ETH_MAC_ADDR PRP MAC Address 
6 UINT Duplicate Discard 
7 UINT Transparent Reception 
8 STRUCT of: PRP Interface Counters 
UDINT Transmit Count A 
UDINT Transmit Count B 
UDINT Transmit Count C 
UDINT Receive Count A 
UDINT Receive Count B 
UDINT Receive Count C 
UDINT Wrong LAN A Count 
UDINT Wrong LAN B Count 
9 STRUCT of: PRP Duplicate Detection Counters 
UDINT Entries Unique Count A 
UDINT Entries Unique Count B 
UDINT Entries Duplicate Count A 
UDINT Entries Duplicate Count B 
UDINT Entries Multiple Count A 
UDINT Entries Multiple Count B 
10 UDINT PRP Proxy Nodes Count 
ll ARRAY of: Proxy Nodes Table 
ETH_MAC_ADDR Proxy Node MAC Address 
12 STRUCT of Path to PRP Nodes Table object 
UINT Path Size 0 
Padded EPATH Path 
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5-14 PRP Nodes Table Object 
Class Code: 57 Hex 
5-14.1 Scope 
The PRP Nodes Table Object keeps the record of all PRP Capable nodes that have been 
detected on the network. 
PRP Capable Devices participating in a PRP network MAY implement one or more instances 
of the PRP Nodes Table Object. 
5-14.2 Revision History 
Revision Reason for Object Definition Update 
1 Initial revision of this object definition 
5-14.3 Attributes 
5-14.3.1 Class Attributes 
The PRP Nodes Table Object shall support the following class attributes. 
Table 5-14.1 Class Attributes 
Attribute Need in Access | NV Name Data Description of Semantics of Values 
ID Implementation Rule Type Attribute 
1 Conditional ' Get Vv Revision | UINT Revision of this object | The minimum value 
shall be 1 
2 Required Get Vv Max UINT Maximum instance The largest instance 
Instance number of an object number of a created 
currently created in object at this class 
this class level of the hierarchy level 
device 
3 Required Get Vv Number UINT Number of object The number of object 
of instances currently instances at this class 
Instance created at this class hierarchy level 
level of the device 
4thru7 | These class attributes are optional and are described in Volume 1, Chapter 4 


Table Footnotes 


1 Required if the Revision value is greater than 1, Optional otherwise. 


— 5-91 - 
Edition 1.18 
SINGLE SUBSCRIPTION ONLY; SUBSCRIPTION TERMS AND CONDITIONS OUTLINED ON PAGE (iii) 


Volume 2: EtherNet/IP Adaptation of CIP, Chapter 5: Object Library 


PRP Nodes Table Object, Class Code: 57 Hex 


5-14.3.2 Instance Attributes 
The PRP Nodes Table Object shall support the following instance attributes. 
Table 5-14.2 Instance Attributes 


Attr Need in Access NV Name Data Type Description of Semantics of 
ID Implem Rule Attribute Values 
1 Required Get v PRP Nodes Table | UDINT Number of Nodes in 
Count the PRP Nodes 
Table 
2 Required Get Vv PRP Nodes Table | ARRAY of: 
STRUCT of 
Node MAC ETH_MAC_ MAC address of the 
Address ADDR source node as 
advertised by the 
PRP Supervision 
frame 
Time Last UDINT Time in TimeTicks 
Seen A (1/100s) since the 


last frame from this 
remote LRE was. 
received over LAN 
A. Initialized with 
a value of 0 upon 
node registration. 


Time Last UDINT Time in TimeTicks 
Seen B (1/100s) since the 
last frame from this 
remote LRE was 
received over LAN 
B Initialized with a 
value of 0 upon 
node registration. 


5-14.4 Common Services 
The PRP Node Table Object provides the following common services. 
Table 5-14.3 PRP Node Tables Object Common Services 


i Need in Implementation 
Cc pegneg E Service Name Description of Service 
‘ode (Hex) Class Instance 
0x01 Optional Required Get_Attributes_All Returns multiple attributes in numerical order. 
Ox0E Required Required Get_Attribute_Single Returns a single attribute 
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PRP Nodes Table Object, Class Code: 57 Hex 


5-14.5.1 Class Level 


At the class level, the Get_Attributes_All response shall contain the class attributes in 
numerical order, up to the last implemented attribute. Any unimplemented attributes in the 
response shall use the default attribute values. 


5-14.5.2 Instance Level 


At the instance level the Get_Attributes_All response shall be as follows. 
Table 5-14.4 Get_Attributes_All Response 


Default Value 
Attribute ID Data Type Attribute Name (if not implemented) 
1 UDINT PRP Nodes Table Count 
2 ARRAY of: PRP Nodes Table 
STRUCT of: Table Entry 

ETH_MAC_ADDR Node MAC Address 

UDINT Time Last Seen A 

UDINT Time Last Seen B 
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Introduction 

This chapter defines which objects are required, optional and conditional for an EtherNet/IP 
device and contains device profiles that are EtherNet/IP specific. 

EtherNet/IP Object Requirements 


At minimum, every EtherNet/IP device shall implement the EtherNet/IP specific objects 
specified in Table 6-2.1, in addition to the objects specified by its Device Profile. See Volume 
1, Chapter 6 for more information on Device Profiles. 


Table 6-2.1 EtherNet/IP Link Object Requirements 


Object Class Requirement # of Instances 
TCP/IP Interface (OxF5 — see section 5-4) Required 1 per interface 
Ethernet Link (0xF6 —see section 5-5 and 6-3) Conditional! 1 per IEEE 802.3 interface 
DLR Object (0x47 — see section 5-6) : —| Conditional? a 1 : - —- 
QoS Object (0x48 - see section 5-7) Conditional® 1 


Table Footnotes 

1. If an Ethernet medium is used, the corresponding link object shall be the Ethernet Link object. If any 
other medium is used, the vendor shall define a vendor specific link object. 
Required for devices that implement Device Level Ring (see section 9-5). 

3. Required for devices that support sending EtherNet/IP messages with nonzero DiffServ code points 
(DSCP), or sending EtherNet/IP messages in 802.1Q tagged frames, such as devices that support DLR 
and CIP Motion (e.g., see the CIP Motion Drive Device Profile in Chapter 6 of Volume 1). 


NOTE: This specification permits the use of any medium that supports TCP/IP; however, only 
the Ethernet medium has been completely standardized here. It is likely in the future that 
ODVA/CI will standardize other link objects for frequently used TCP/IP media. For example, 
in the future, a standardized PPP object may be defined. 


Although it does not have an object class code, each device shall also implement the CIP 
Unconnected Message Manager (UCMM). 


Figure 6-2.1 Base Device Object Model 
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6-3 


Devices with Multiple Interfaces 
EtherNet/IP devices may implement multiple network interfaces, for example: 


e A device with a single IP address with two Ethernet ports implemented as an embedded 
switch 

e An EtherNet/IP-enabled switch with multiple Ethernet ports and with EtherNet/IP 
communications for the switch itself 

e A device with a single Ethernet interface and multiple IP addresses 


Note: The specification does not address any behavior related to the Ethernet switching 
function in the device examples mentioned above. The intent of the specification at present is 
only to specify to allowable configurations of TCP/IP Interface Object and Ethernet Link 
Object instances in order to support the device possibilities above. 


Devices with multiple interfaces shall implement multiple instances of the TCP/IP interface 
Object and physical link objects (e.g., Ethernet Link Object) as applicable to the device 
function as listed below: 


e 1 instance of the TCP/IP Interface Object for each TCP/IP interface (i.e., for each IP 
address). 

e | instance of a physical link object (e.g., Ethernet Link Object) for each physical interface 
exposed via EtherNet/IP. Devices may elect not to expose all interfaces, 

e Devices may use a physical link object instance (e.g., Ethernet Link Object) for an internal 
interface such as the internal device port of an embedded switch. 

e Devices with multiple IP addresses may elect to represent each IP interface as a different 
CIP port, and allow CIP messages to be routed from one port to the other. For example, 
the CIP connection path would enter one of the ports and exit the other port. In this 
scenario, the device shall implement one instance of the Port Object for each CIP port, and 
shall implement the CIP routing mechanism described in Volume 1. Devices are not 
required to implement the Port Object unless they implement multiple CIP ports. 


The following sections illustrate some of the different possibilities for devices with varying 
numbers of Ethernet interfaces. 
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6-3.1 Case 1: Single Port Device, 1 IP Address 


This is the normal case for most EtherNet/IP devices : single Ethernet interface, single IP 
address. In this case, there is one instance of the TCP/IP Interface Object, and one instance of 
the Ethernet Link Object that represents the physical interface. 


Figure 6-3.1 Case 1 Illustration 


TCP/IP 
Interface 
Object 


Ethernet 
Link Object 


6-3.2 Case 2, Single Port Device, Multiple IP Addresses 


Example : A device with a single Ethernet interface wishes to expose a second IP address. 


In this example, there are 2 instances of the TCP/IP Interface Object, and one instance of the 
Ethernet Link Object that represents the physical interface. TCP/IP Interface Object class 
attributes 2 (Max. instances) and 3 (Number of instances) are used. The instance attribute 4 
(Physical Link Object) of both instances refers to the same Ethernet Link Object 

Figure 6-3.2 Case 2 Illustration 
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6-3.3 


6-3.4 


Case 3, Device with 2 Ethernet ports. Each port has an associated IP Address 


Example : A device with a multiple Ethernet interfaces, each with an associated IP address. 
Each interface would be a different CIP-addressable port (i.e., there would be a Port Object 
instance per interface). 

In this example, there are 2 instances of the TCP/IP Interface Object, and 2 instances of the 
Ethernet Link Object that represent each the physical interface. TCP/IP Interface Object / 
Ethernet Link Object class attributes 2 (Max. instances) and 3 (Number of instances) are used. 
The new Ethernet Link instance attribute 10 (Interface Label) is used to get the correlation 
between the Ethernet Link Object and the physical port. 


Figure 6-3.3 Case 3 Illustration 
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Note: this example can be generalized to more than 2 ports. 


Case 4, Device with Multiple Ethernet interfaces and a single IP Address and CIP 
Interface 


Example:An example is a device with embedded switch technology (to support linear 
topology), or an EtherNet/IP-enabled switch. In this case, the device has multiple Ethernet 
interfaces, but the interfaces are not CIP-addressable ports (i.e., they do not have corresponding 
CIP port numbers or Port Object instances). 


It is however useful to allow configuration of the Ethernet interfaces, for example to set port 
speed and duplex via the Ethernet Link Object. Note that there is no intent to specify switching 
behavior of the device. 


In this case, there is a single instance of the TCP/IP Interface Object, an optional “internal” 
instance of the Ethernet Link Object (corresponding to the internal device port), and then 
Ethernet Link Object instances for each of the physical interfaces. 


New Ethernet Link Object class attributes 2 (Max. instances) and 3 (Number of instances) are 
used. The new Ethernet Link instance attribute 10 (Interface Label) is used to get the 
correlation between the Ethernet Link Object and the physical port. The new Ethernet Link 
instance attribute 7 (Interface Type) defines the kind of object (internal/external). 


~6-6— 
Edition 1.18 
SINGLE SUBSCRIPTION ONLY; SUBSCRIPTION TERMS AND CONDITIONS OUTLINED ON PAGE (iii) 


Volume 2: EtherNet/IP Adaptation of CIP, Chapter 6: Device Profiles 


Figure 6-3.4 Case 4 Illustration 
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Refer to Chapter 5 (Object Library) for specific EtherNet/IP object definitions and 
requirements. 


6-3.5 Case 5, Managed Ethernet Switch Devices supporting RSTP 


Case 5 adds RSTP to Managed Ethernet Switch Device profiles. In this case, there SHOULD 
be at least one instance of the RSTP Bridge Object per device. And there SHALL be one 
instance of the RSTP Port Object for each port supporting RSTP. Each instance of the RSTP 
Bridge Object is associated with at least two instances of RSTP Port Objects. 


RSTP Port Object class attributes 2 (Max instances) and 3 (Number of instances) are used. The 
RSTP Port Object instance attribute 4 (Port MAC Address) is used to get the correlation 
between the RSTP Port Object and the external physical port supporting RSTP. 
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Figure 6-3.5 Case 5 Illustration 
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6-4 


6-4.1 


6-4.1.1 


6-4.1.2 


Managed Ethernet Switch Device Type: 2Cpex 


Managed Ethernet Switch Device 

Device Type: 2C Hex 

The Managed Ethernet Switch Device type represents a computer networking device that 
connects network segments. It represents a managed network bridge that processes and 
switches data at the Data link or Network layers of the OSI network model. 

Object Model 


All Objects Present in a Device 


The Object Model in Table 6-4.1 represents the minimum support in a Managed Ethernet 
Switch Device. The table below indicates: the object classes present in this device, whether or 
not the class is required, and the number of instances present in each class. 
Table 6-4.1 Objects Present in an EtherNet/IP Switch Device 
Object Class Optional/Required # of Instances 
* ‘ 7 1 
Tdentity. Object Required See Volume 1, Section 5A-2 
1 
Message Rx Object Required 
esbape kunt usec nS See Volume 1, Section SA-3 
N 
Ethernet Link Object Required (where N is the number of ports in a CIP Switch 
Device) 
See Volume 2, Section 5-5 
At least | 
TCP/IP Interface Object Required 
BMD Be ee qe See Volume 2, Section 5-4 
Connection Manager Required 1 
Object 4 See Volume 1, Section SA-7 
1 
Bas ‘itch Object Required 
ese Switeh Object nae See Volume 2, Section 5-7 
: a At least 1 (input assembly) 
Assembly Object Ri d 
ssembly Object a See Volume 1, Section SA-5 
1 
Time Sync Object ional 
MBeoyne ect Optona See Volume 1, Section SB-3 
1 
, ‘cual 
QoS Object Optional See Volume 2, Section 5-7 
= 2 7 V (Number of VLANS) 
TP Bi of i 
a ridge Object ‘Options! See Volume 2, Section 5-11 


Components that Affect Behavior 


The components (object, attribute, or service) that affect the behavior of an EtherNet/IP Switch 
device are specified in the table below. 
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Managed Ethernet Switch Device Type: 2CHex 
Table 6-4.2 Components That Affect Behavior of an EtherNet/IP Switch Device 


Component Effect on Behavior 
Identity Object See Volume 1, Section 6-2.2 for Details 
Message Router Object See Volume 1, Section 6-2.2 for Details 
Ethernet Link Object See Volume 1, Section 6-2.2 for Details 
TCP/IP Interface Object See Volume 1, Section 6-2.2 for Details 
Connection Manager Object | See Volume 1, Section 6-2.2 for Details 
Assembly Object See Volume 1, Section 6-2.2 for Details 
Base Switch Object Provides base switch attributes 


Provides Precision Time Synchronization per the IEEE- 
1588 Standard 

This object only applies to the traffic to and from the 
switch as a target device 


Time Sync Object 


QoS Object 


Provides the configuration and diagnostics interface for 


RSTP Bridge Object the RSTP protocol 


6-4.1.3 Object Interfaces 
The objects in this device have the interfaces listed in the following table: 


Table 6-4.3 Object Interfaces 


Object Interface 

Identity Object Message Router 

Message Router Object Message Router 

Ethernet Link Object Message Router 

TCP/IP Interface Object Message Router 

Connection Manager Object | Message Router 

Assembly I/O Connection or Message Router 

Base Switch Object Message Router, Assembly Object, or Parameter Object 
Time Sync Object Message Router, Assembly Object, or Parameter Object 
QoS Object Message Router 

RSTP Bridge Object Message Router, Assembly Object or Parameter Object 

6-4.2 I/O Assembly Instances 


The following table defines the Managed Ethernet Switch Device assembly instances: 


Table 6-4.4 I/O Assembly Instances - Managed Ethernet Switch Device 


eer Required/Optional Type Name 
1 Required Input Power Source and Link Status 
2, Optional Input Global Admin State 
3 Optional Input Contact Status 
4 Optional Input Combination 
50 Optional Output Port Admin State 
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6-4.3 


6-4.3.1 


6-4,3.2 


6-4.3.3 


6-4.3.4 


Managed Ethernet Switch Device Type: 2Cpex 
V/O Assembly Data Attribute Formats 


Power Source and Link Status Input Assembly 


The Power Source and Link Status Input Assembly is defined in the following table: 


Table 6-4.5 Input Assembly Instance — Power Source and Link Status 


Instance | Byte Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 
1 0 Power Source Status (Least Significant Byte) 
1 Power Source Status (Most Significant Byte) 


2-5 Global Link Status DWORD 0 


6-9 Global Link Status DWORD 1 


10-13 | Global Link Status DWORD 2 


14-17 | Global Link Status DWORD 3 


This assembly provides for up to 128 ports. For switches with less than 128 ports leave unused 


ports as 0. 


Global Admin State Input Assembly 


The Global Admin State Input Assembly is defined in the following table: 


Table 6-4.6 Input Assembly Instance - Global Admin State 


Instance | Byte Bit7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 
2 0-3 Global Admin State DWORD 0 
47 Global Admin State DWORD 1 


8-11 Global Admin State DWORD 2 


12-15 | Global Admin State DWORD 3 


This assembly provides for up to 128 ports. For switches with less than 128 ports leave unused 


ports as 0. 


Contact Status Input Assembly 
The Contact Status Input Assembly is defined in the following table: 
Table 6-4.7 Input Assembly Instance — Contact Status 


Instance | Byte | Bit7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 
3. 0 Contact Status (Least Significant Byte) 
1 Contact Status (Most Significant Byte) 


Combination Input Assembly 


The Combination Input Assembly is defined in the following table: 
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Managed Ethernet Switch Device Type: 2Cpex 


Table 6-4.8 Combination Input Assembly Instance 


Instance | Byte Bit7 Bit 6 Bit 5 Bit4 Bit 3 Bit 2 Bit 1 Bit 0 
4 0 Power Source Status (Least Significant Byte) 
1 Power Source Status (Most Significant Byte) 
2 Contact Status (Least Significant Byte) 
3 Contact Status (Most Significant Byte) 
4-7 Global Link Status DWORD 0 
8-11 Global Link Status DWORD 1 
12-15 | Global Link Status DWORD 2 
16-19 | Global Link Status DWORD 3 
20-23 | Global Admin State DWORD 0 
24-27 | Global Admin State DWORD 1 
28-31 | Global Admin State DWORD 2 
32-35 Global Admin State DWORD 3 


This assembly provides for up to 128 ports. For switches with less than 128 ports leave unused 


ports as 0. 


6-4.3.5 Port Admin State Output Assembly 
The Port Admin State Output Assembly is defined in the following table: 


Table 6-4.9 Output Assembly Instance — Port State 


Instance Byte Bit7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 
50 0-3 Global Admin State DWORD 0 
4-7 Global Admin State DWORD 1 
8-11 Global Admin State DWORD 2 
12-15 | Global Admin State DWORD 3 
This assembly provides for up to 128 ports. For switches with less than 128 ports leave unused 
ports as 0. 
6-4.4 Mapping I/O Assembly Data Attribute Components 


The following table indicates the I/O assemb 
Ethernet Switch device. 


Table 6-4.10 I/O Assembly Data Attribute Components 


ly Data attribute mapping for the Managed 


Data Component Name Class Instance Attribute 
Name Number SUT Name Number 
Power Source Status Base Switch 51 Hex 1 Power Source 4 
Global Admin State Base Switch 51 Hex 1 Global Port Admin State 7 
Global Link Status Base Switch 51 Hex 1 Global Port Link Status 8 
Contact Status Base Switch 51 Hex ll Contact Status 10 
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Volume 2: EtherNet/IP Adaptation of CIP 


Chapter 7: Electronic Data Sheets 


=T= 
Edition 1.18 
SINGLE SUBSCRIPTION ONLY; SUBSCRIPTION TERMS AND CONDITIONS OUTLINED ON PAGE (iii) 


Volume 2: EtherNet/IP Adaptation of CIP, Chapter 7: Electronic Data Sheets 


Contents 
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TA 

7-5 
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qe 
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7-1 Introduction 


This chapter of the EtherNet/IP specification contains additions to the definition of electronic 
data sheets (EDS) that are EtherNet/IP specific. See Volume 1, Chapter 7 for more information 
about the format of electronic data sheets and the definition of EDS related terms such as EDS 
section, EDS entry and EDS field. 


7-2 Common Object Class Information 


7-21 Object Class Sections 


The following table identifies section keywords that are used to publicize EtherNet/IP object 
class information. Each of the following EDS Section Keywords may contain any of the 
Common Object Class Entry Keyword(s) described in Volume 1, section 7-3.6.1.2. The 
following table contains EtherNet/IP object class section names. 


Table 7-2.1 Object Class Section Keywords 


CIP Object Section Keyword Name Required/Optional See section 
Device Level Ring Object DLR Class] Conditional * 7-6 
47 hex 
QoS Object QoS Class] Optional 
48 hex 
Base Switch Object Base Switch Class] Optional 
51 hex 
SNMP Object SNMP Class] Conditional * 
52 hex 
RSTP Bridge Object RSTP Bridge Class] Conditional * 7-8 
54 hex 
RSTP Port Object RSTP Port Class] Conditional * 7-9 
55 hex 
Parallel Redundancy PRP Class] Conditional * 7-10 
Protocol Object 
56 hex 
PRP Nodes Table Object PRP Nodes Table Class] Conditional * 
57 hex 
TCP/IP Interface Object [TCP/IP Interface Class] Conditional | 7-7 
FS hex 
Ethernet Link Object [Ethernet Link Class] Conditional ? 7-3 
F6 hex 


Table Footnotes 

1 Required if device supports QuickConnect functionality 

2 Required if more than one Ethernet port exists on this device 

3 Required if the device implements this CIP object class, otherwise not allowed 


= 73= 
Edition 1.18 
SINGLE SUBSCRIPTION ONLY; SUBSCRIPTION TERMS AND CONDITIONS OUTLINED ON PAGE (iii) 


Volume 2: EtherNet/IP Adaptation of CIP, Chapter 7: Electronic Data Sheets 


7-3 


7-3.1 


7-3.2 


[Ethernet Link Class] Section 


The Ethernet Link Class section defines the characteristics of the Ethernet Link Object (see 
Chapter 5, Object Library) implemented in this device. The Common Object Class keywords 
may be used in the Ethernet Link Class section, see Volume 1, section 7-3.6.1. The table below 
shows the additional entries in the Ethernet Link Class section. The Ethernet Link Class section 
begins with the keyword [Ethernet Link Class]. 


Table 7-3.1 Entry Keywords in the Ethernet Link Class Section 


Entry Name Entry Keyword Required/Optional 
Interface Label InterfaceLabelN Conditional ' 
Interface Type InterfaceTypeN Optional 


1 Required if more than one Ethernet port exists on this device 


Interface Label 


The Interface label shall specify the Ethernet port interface label. The entry keyword for all 
Ethernet port interface labels shall consist of the character array “InterfaceLabel”, combined 
with a decimal number corresponding to an instance of the Ethernet link object. For example, 
InterfaceLabel1 is the Interface Label attribute of instance 1 of the Ethernet link object. 


Table 7-3.2 Interface Label Keyword Format 


Field Name Field Number Data Type Required/Optional 


Interface Label 1 STRING Required 


e Interface Label — specifies the name of this Ethernet port. The value of the Interface 
Label field shall be the same as the Interface Label attribute. 


Example: 
InterfaceLabell = "Port 1"; 
InterfaceLabel2 = "Port 2"; 


Interface Type 


The Interface type shall specify the Ethernet port interface type. The entry keyword for all 
Ethernet port interface types shall consist of the character array “InterfaceType”, combined 
with a decimal number corresponding to an instance of the Ethernet link object. For example, 
InterfaceTypel is the Interface Type attribute of instance 1 of the Ethernet link object. 


Table 7-3.3 InterfaceType Keyword Format 


Field Name Field Number Data Type Required/Optional 


Interface Type 1 USINT Required 


e Interface Type — specifies the type of this Ethernet port. See the Ethernet Link Object 
definition in Volume 2, Chapter 5, “Interface Type” section, for a definition of the valid 
values for the Interface Type field. The value of the Interface Type field shall be the 
same as the Interface Type attribute. 


Example: 
InterfaceTypel = 2; $ Twisted pair 
InterfaceType2 = 3; $ Optical fiber 
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7-4 


7-5 


[Device Classification] Section 


In the [Device Classification] section of the EDS, for any EtherNet/IP compliant device, there 
shall be at least one ClassN keyword entry with its first field set to EtherNetIP. As shown in 
Figure 7-5.1, no sub-classifications shall be present. 


[Port] Section 


In the [Port] section of the EDS (see Figure 7-5.1 for an example), the PortN entry 
corresponding to the EtherNet/IP compliant port shall be set as follows: 


The “Port Type Name” field shall have a value of “TCP”. 


The optional “Port Object” field shall be set to the path of the TCP/IP Interface Object for this 
port. 


No additional requirements, beyond those in the CIP Common Specification (Volume 1), are 
placed on the “Port Name” and “Port Number” fields. 


NOTE: An EDS for an EtherNet/IP device does not directly refer to the link object for the 
EtherNet/IP port (for example, the Ethernet Link Object) since it can be referenced through the 
TCP/IP Interface Object for the port. 


Figure 7-5.1 Example EDS of an EtherNet/IP Device 


[File] 
DescText = "Widget EDS File"; 
CreateDate = 02-07-1997; 
CreateTime = 17:51:44; 
ModDate = 04-06-1997; 
ModTime = 22:07:30; 
Revision = 2.1; 
HomeURL = "http://www.widget-—works.com/EDS/12345.eds"; 


[Device] 


VendCode = 65535; 


VendName = "Widget-Works, Inc."; 
ProdType = 0x2B; 
ProdTypeStr = "Generic Device"; 


ProdCode = 10; 


ProdName = "Smart-Widget"; 
Catalog = "1492-SW"; 
Icon = "widget.ico"; 


[Device Classification] 
Classl = EtherNetIP; 


[Port] 
Portl = 
TCP, 
"EtherNet/IP port", 
"20 FS 24 01", 
2; 
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7-6.1 


7-6.1.1 


7-6.2 


7-6.2.1 


[DLR Class] Section 


The DLR Class section defines the characteristics of the DLR Object (see Chapter 5, Object 
Library) implemented in this device, if a DLR Object implementation exists. The Common 
Object Class keywords may be used in the DLR Class section (see Volume 1, section 7-3.6.1). 
The DLR Class section begins with the keyword [DLR Class]. This section is required if the 
device supports the DLR object. 


Table 7-6.1 Additional Entry Keywords in the DLR Section 


Entry Name Entry Keyword Required/Optional 
Ring Supervisor Capable | Ring_Supervisor_Capable Conditional! 
Redundant Gateway Redundant_Gateway_Capable Conditional” 
Capable 


Table Footnotes 
1 Required if the device is capable of being the ring supervisor 
2 Required if the device is capable of being a redundant gateway 


Ring Supervisor Capable Entry keyword 


The "Ring_Supervisor_Capable" entry keyword is conditional and shall contain the formatted 
field shown in Table 7-6.2. If the device is capable of being a ring supervisor the keyword is 
required. If the device is not capable of being a ring supervisor the keyword is optional. If this 
keyword is omitted, the device is not capable of being the ring supervisor. 


Table 7-6.2 Ring_Supervisor_Capable Keyword Format 


Field name Field Number Data type Required/Optional 
Supported 1 Field Keyword, possible values: Yes, No | Required 
Supported, Field 1 


This field indicates if the device can be the ring supervisor. If the field value is “Yes”, the 
device can be the ring supervisor. If the field value is “No”, the device cannot be the ring 
supervisor. 


Redundant Gateway Capable Entry keyword 


The "Redundant_Gateway_Capable" entry keyword is conditional and shall contain the 
formatted field shown in Table 7-6.3Table 7-6.3. If the device is capable of being a redundant 
gateway the keyword is required. If the device is not capable of being a redundant gateway the 
keyword is optional. If this keyword is omitted, the device is not capable of being a redundant 
gateway. 


Table 7-6.3 Redundant_Gateway_Capable Keyword Format 


Field name Field Number Data type Required/Optional 


Supported 1 Field Keyword, possible values: Yes, No Required 


Supported, Field 1 


This field indicates if the device can be a redundant gateway. If the field value is “Yes”, the 
device can be a redundant gateway. If the field value is “No”, the device cannot be a redundant 
gateway. 
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7-7 


7-7.1 


[TCP/IP Interface Class] Section 


The TCP/IP Interface Class section defines the characteristics of the TCP/IP Interface Object 
(see Volume 2, Chapter 5, Object Library) implemented in this device. The Common Object 
Class keywords may be used in the TCP/IP Interface Class section, see Volume 1, section 7- 
3.6.1. The table below shows the additional conditional entries in the TCP/IP Interface Class 
section. The TCP/IP Interface Class section begins with the keyword [TCP/IP Interface Class]. 


Table 7-7.1 Entry Keywords in the TCP/IP Interface Class Section 


Entry Name Entry Keyword Field Name Required/Optional 
EtherNet/IP QuickConnect ENetQCTN Ready for Connection Time Conditional ! 
Target 
EtherNet/IP QuickConnect ENetQCON Connection Origination Time Conditional ? 
Originator 


Table Footnotes 
1, Required if a target device supports QuickConnect functionality 
2. Required if a connection originator establishes connections to a QuickConnect target device 


The entry keywords for all ports shall consist of the character array “ENetQCT” or 
“ENetQCO”, combined with a decimal number corresponding to an instance of the TCP/IP 
object. For example, ENetQCT1 is instance 1 of the TCP/IP Object. 


ENetQCTN Keyword 
Table 7-7.2 ENetQCTN Keyword Format 
Field Name Field Number Data Type Required/Optional 
Ready for Connection Time 1 UINT Required 
CIP Connection Time 2 UINT Required 


The first field, “Ready for Connection Time”, indicates the time, in milliseconds, from the 
application of device power to the production of the first Gratuitous ARP message, and its 
readiness to accept a TCP connection when the QuickConnect ports are set for forced speed 
and duplex and Auto-MDIX is disabled. 


The second field, “CIP Connection Time” indicates the accumulated time in milliseconds for 
the following events: 


a) Time from reception of ARP Request to ARP response 
b) Time from reception of TCP open request to establishment of TCP connection 
c) Time from reception of Register Session request to Register Session response 


d) Time from reception of the Forward Open for the CIP I/O Connection to when it can 
produce its first I/O data message (this includes processing the Forward Open, applying 
any configuration data from the data segment, and generating the Forward Open response). 

Example 

[TCP/IP Interface Class] 

ENetQCT1=350, 50; $ 350ms Ready for Connection time 


$ 50ms Accumulated CIP Connection Time 
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7-7.2 ENetQCON Keyword 
Table 7-7.3 ENetQCON Keyword Format 


Field Name Field Number Data Type Required/Optional 
Connection OriginationTime 1 UINT Required 


The field, “Connection Origination Time”, indicates the accumulated time in milliseconds for 
the following events: 


a) Time from when the controller receives the “Electrically Locked” input signal to when it 
can send the TCP open request (or ARP if one is needed). 


b) Time from the establishment of the TCP connection to the Register Session request. 
c) Time from reception of Register Session response to the Forward Open request. 


d) Time from reception of the Forward Open response to the first output data on the I/O 
connection. 


The connection origination time should be based on a best-case system where the system has to 
open up to seven connections to QuickConnect nodes on the tool. It is understood that if there 
are fewer or more than this number of nodes on the tool, this time will vary. The vendor of the 
controller shall describe in the product’s documentation the conditions under which the best- 
case time was achieved and provide guidance as to the impact on this time under other 
conditions, e.g. - number of standard I/O connections, user program scan time, I/O connection 
performance (RPI) that provides the electrical-lock signal to the controller. 


Example 
[TCP/IP Interface Class] 


ENetQCO1=50; $ 50ms Accumulated Connection Origination Time 


=71S— 
Edition 1.18 
SINGLE SUBSCRIPTION ONLY; SUBSCRIPTION TERMS AND CONDITIONS OUTLINED ON PAGE (iii) 


Volume 2: EtherNet/IP Adaptation of CIP, Chapter 7: Electronic Data Sheets 


7-8 


[RSTP Bridge Class] Section 


The RSTP Bridge Class section defines the characteristics of the RSTP Bridge Object (see 
Volume 2, Chapter 5, Object Library) implemented in this device, if the RSTP Bridge Object | 
implementation exists. The Common Object Class keywords may be used in the RSTP Bridge 
Class section (see Volume 1, section 7-3.6.1). The RSTP Bridge Class section begins with the | 
keyword [RSTP Bridge Class]. This section is required if the device supports the RSTP Bridge 
Object. 
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7-9 [RSTP Port Class] Section 


The RSTP Port Class section defines the characteristics of the RSTP Port Object (see Volume 
2, Chapter 5) implemented in this device, if the RSTP Port Object implementation exists. The 
Common Object Class keywords may be used in the RSTP Port Class section (see Volume 1 
section 7-3.6.1). The RSTP Port Class section begins with the keyword [RSTP Port Class]. 
This section is required if the device supports the RSTP Port Object. 
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7-10 


7-10.1 


7-10.1.1 


7-10.1.2 


7-10.2 


[PRP Class] Section 


The PRP Class section defines the characteristics of the PRP Object (see Chapter 5, Object 
Library) implemented in this device, if the PRP Object implementation exists. The Common 
Object Class keywords may be used in the PRP Class section (see Volume_1, section 7-3.6.1). 
The PRP Class section begins with the keyword [PRP Class]. This section is required if the 
device supports the PRP Object. 


Table 7-10.1 Additional Entry Keywords in the PRP Section 


Entry Name Entry Keyword Required/Optional 
Proxy Table Support Proxy_Table_Support Required 
Nodes Table Support Nodes_Table_Support Conditional! 


Table Footnotes: 
1. Required if PRP device supports a PRP Nodes Table 


Proxy Table Support Entry keyword 


The “Proxy_Table _Support” entry keyword is required and shall contain the formatted field 
shown in Table 7-10.2. If the device is capable of supporting a Proxy Nodes Table the 
keyword is required. If the device is not capable of supporting a Proxy Nodes Table the 
keyword is optional. If this keyword is omitted, the device in not capable of supporting a 
Proxy Nodes Table. 


Table 7-10.2 Proxy Table Support Keyword Format 


Field Name Field Number Data Type Required/Optional 
Supported 1 Field Keyword: Yes, No Required 
Max Table Size 2 UDINT Required 


Supported, Field 1 


This field indicates that the device supports a Proxy Nodes Table. If the field value is “Yes”, 
the device can support proxy nodes tables. If the field value is “No”, this device cannot support 
any Proxy Nodes tables. 


Max_Table_Size, Field 2 


This field indicates the maximum size Proxy Nodes Table this device can support. 


Nodes Table Support Entry keywork 


The “Nodes_Table Support” entry keyword is conditional and shall contain the formatted field 
shown in Table 7-10.3. If the device is capable of supporting a PRP Nodes Table the keyword 
is required. If the device is not capable of supporting a PRP Nodes Table the keyword is 
optional. If this keyword is omitted, the device in not capable of supporting a PRP Nodes 
Table. 


Table 7-10.3 Nodes_Table_Support Keyword Format 


Field Name Field Number Data Type Required/Optional 
Supported 1 Field Keyword: Yes, No Required 
Max Table Size 2 UDINT Required 
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7-10.2.1 Supported, Field 1 


This field indicates that the device supports a PRP Nodes Table. If the field value is “Yes”, the 
device can support PRP nodes tables. If the field value is “No”, this device cannot support any 
PRP Nodes tables. 


7-10.2.2. Max_Table_Size, Field 2 


This field indicates the maximum size PRP Nodes Table this device can support. 
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8-1 


8-2 


8-4 


Introduction 


Chapter 8 specifies EtherNet/IP media and physical layer requirements for EtherNet/IP 
installations and active devices. In some cases, industrial environmental requirements may 
exceed those used in office environments. Products and components may need to be enhanced 
to provide the level of performance required to support industrial applications. Some of these 
enhancements include noise rejection, sealing, voltage isolation, chemical resistance, shock, 
vibration and wide/dynamic temperature ranges. 


General 


The following sections will delineate physical layer media variants for EtherNet/IP. This 
standard does not define requirements for coaxial Ethernet components or commercial off the 
shelf components (COMMERCIAL). Requirements for these components can be found in 
ANSI IEEE 802.3 standard and TIA 568 standards. In this chapter, components that fall under 
these standards will be referred to as “standard components”. Systems constructed of standard 
components have been deployed in industrial environments primarily in information systems 
and limited control applications. These systems, for the most part, have been successfully 
providing services at 10 Mbps. Whether providing services at 10 Mbps or 100 Mbps, standard 
components are recognized and acceptable for use within the guidelines of this specification. 
However, because testing has shown that in order to survive harsh environments both in high 
noise, diverse temperatures and the presence of chemicals both in liquid and solid forms, there 
are system and component enhancements that are required. 


This document defines component performance up to 100 Mbps. The component 
specifications herein are optimized for data rates of 10 Mbps and 100 Mbps. The copper variant 
shall include both shielded and unshielded twisted pair cable technologies. The signaling and 
coupling for copper twisted pair methods are described in section 8-9.2.1. Products constructed 
with Commercial components are not eligible for the industrial conformance check mark since 
the Commercial products cannot be directly mapped into any controlling standards controlled 
by ODVA. Products constructed of Commercial components are eligible for the Commercial 
checkmark. 


Grounding (earthing) and Bonding 

Grounding and bonding in the communications coverage area is critical to the performance of 
EtherNet/IP networks. This topic is a subject of further study. 

Environmental Compatibility 

Products and components installed in EtherNet/IP networks shall be compatible with the local 
environmental conditions either by design or a combination of design and mitigation. 


Auxiliary Power 


For auxiliary power connector styles and pin outs see Section 8-2 and 8-3 of Volume | of the 
CIP Networks Library. 
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8-6 


Supported Physical Topologies and relation to other networks 


Figure 8-6.1 shows how EtherNet/IP maybe connected to other CIP networks and the generic 
telecommunications infrastructure. Connection to the generic telecommunications 
infrastructure should be through an appropriate security device to prevent inadvertent 
interruption to the control networks. The industrial generic cabling systems may not provide a 
level of performance required for control of industrial machinery and processes. The cabling is 
connected to the generic cabling as defined by ISO/IEC 24702 and TIA 1005 through an 
Automation Outlet (AO). The requirements of the automation outlet are defined in this chapter. 


Figure 8-6.1 Relationship to Other Networks 


{ AO EtherNevIP 


ToGeneric cabling | NA) vO pic | | Linking Linking 
system device device 
according to 
ISO/IEC24702 
ControlNet 
Coupling/ | Linki 
ark HMI} | VO |) PLO] | gone’ 
Potentially explosive area adaptor | levice 
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adaptor 


ControlNet IS DeviceNet 
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There are three basic topologies for Ethernet based networks. EtherNet/IP supports all three of 
the standard active physical topologies as detailed in Figure 8-6.2. 


* Components are to be IS rated 


Figure 8-6.2 Active Physical Topologies 


0-0 0 0 0 


Linear Bus 


Ring 


Star O Node 


A switching device is expected to be a dedicated device usually located in the center of the star 
physical topology. For other topologies such as the physical linear bus and ring the switching 
device may be embedded in a node. A physical linear bus and ring device requires two physical 
connections to the cabling infrastructure. 
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8-7.1 
8-7.1.1 


8-7.1.2 


8-7.2 
8-7.2.1 


8-7.2.2 


8-8 


8-8.1 
8-8.1.1 


Performance Levels 


Sections 8-7.1and 8-7.2 define two levels of product performance: Commercial EtherNet/IP 
and Industrial EtherNet/IP enhanced components. COMMERCIAL cabling components may 
require mitigation in the form of isolation and separation from the various harsh elements 
found in a typical industrial environment. The EtherNet/IP industrial connectivity component 
requirements have added enhancements to reduce the level of mitigation that might otherwise 
be required. This clause also details the requirements for active devices both based on 
COMMERCIAL and industrially hardened in the same way as the cabling components. 


NOTE: There are many sections within this chapter that specify optional requirements. This 
section distills these requirements into two distinct levels: commercial copper and fiber and 
industrial EtherNet/IP copper and fiber. 


COMMERCIAL based EtherNet/IP products 
Copper and Fiber Cabling Components 


The requirements for COMMERCIAL cabling components are defined ANSI/TIA/EIA-568-B 
series standards and section 8-8. The use of COMMERCIAL components may degrade system 
performance. Use of such products or components may result in unsatisfactory performance in 
industrial control applications. 


Active Interfaces (PMD) 


Copper and fiber based COMMERCIAL active products shall meet the minimum requirements 
of this chapter. Since these devices are not expected to be industrial hardened, they may 
require additional mitigation when installed in a harsh environment. The copper interfaces 
shall provide a non-sealed RJ-45 jack at the network interface. The fiber interface shall provide 
connectivity to one of the non-sealed connectors detailed in 8-9.5.2.1 (LC, SC or ST). 


Industrial EtherNet/IP products 
EtherNet/IP Copper and Fiber Cabling Components 


These components are designed to better withstand high noise and harsh environments 
common to the industrial environment. Additional consideration is required for the selection of 
materials in special applications such as robotic and welding applications etc. 


Industrial EtherNet/IP Active Interfaces 


Copper and fiber-based Industrial EtherNet/IP products shall meet all applicable requirements 
of the EtherNet/IP specification, chapter 9. For a product to achieve the Industrial EtherNet/IP 
performance in harsh environments level, the physical layer shall conform to the requirements 
as outlined in section 8-9 of this chapter. 


COMMERCIAL Based EtherNet/IP Products and Physical Layer 


The use of COTS components may degrade system performance. Careful consideration should 
be given to the use of COMMERCIAL components in industrial control applications 


Copper Media 
Cables 


The transmission performance of shielded or unshielded 4 pair twisted pair cables shall meet 
the requirements of ANSI/TIA/EIA-568-B.2 standards and the requirements of E1 columns of 
Table 8-9.4, Table 8-9.5 and Table 8-9.6. 
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8-8.1.2 
8-8.1.2.1 


8-8.1.3 


8-9 
8-9.1 


Connectors 
RJ-45 Connector Variant 


The RJ-45 connectors are the de-facto standard for Ethernet systems. RJ-45 connectors shall 
meet the requirements stated in ANSI/TIA/EIA-568-B.2. In addition IEC 60603-7 series 
defines the mechanical and electrical requirements for the RJ-45 connectors. 


Length Constraints 


The total permanent link length for twisted pair systems is limited to 90m (295 ft). The 
permanent link shall conform to ANSI/TIA/EIA-568-B.1. 


The total channel length for twisted pair systems is 100m (328 ft) including patch cables as 
defined in ANSI/TIA/EIA-568-B.1. Channel and patch cable design and testing shall be in 
accordance with ANSI/TIA/EIA-568-B.1 and ‘B.2 respectively. 


Industrial EtherNet/IP Media and Physical Layer 
Environmental Requirements 


Copper and fiber based Industrial EtherNet/IP products should meet the minimum 
environmental recommendations as defined in Table 8-9.1. Copper and Fiber cabling 
components shall support the requirements in of Table 8-9.2. Active devices shall meet the 
minimum EMI requirements of Table 8-9.2. The values found in Table 8-9.2 represent the 
minimum requirements for IEC light industrial. 
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Table 8-9.1 Minimum Environme 


ntal Recommendations 


Environmental Test Criteria Industry Standard 
Vibration (Unpackaged) 
Frequency Range 10-57Hz 
Displacement 0.3 mm 
TEC 60068-2-6 
57-500Hz 
Acceleration 2g 
Shock (Unpackaged) 
Acceleration 15g (operational) 
5 TEC 60068-2-27 
30g (non-operational) 
Temperature 
Operating range 0°C min. to +60 °C min. * TEC 60068-2-1 
IEC 60068-2-2 
Storage -40 to +70 °C TEC 60068-2-1 
TEC 60068-2-2 


Humidity operating 


5 to 95% RH condensing 


TEC 60068-2-30 


Ingress protection 


IP 20 minimum 


TEC 60529 


Voltage proof (connector only) 


TEC 60512-1 


Contact/contact 


1000 Vd.c. or a.c. peak 


Contact/test panel 


1500 Vd.c. or a.c. peak 


* There may be components or topology de-rating for temperatures below 0 degrees C, or above 60 degrees C. 


Table 8-9.2 Minimum EMI Requi: 


irements for EtherNet/IP Component 


its 


Environmental Test Criteria Industry Standard 
EMI 
ESD 4ky contact 8kv air TEC 61000-6-2 
TEC 61131-2 
TEC 61326-1 
Radiated RF 10V/m @ 80-1000MHz @ 1kHz 
3V/m @ 1.4-2.0GHz @ 1kHz TEC 61000-4-3 
1V/m @ 2.0-2.7GHz @ 1kHz 
Conducted RF | 10V RMS @ 150kHz-80MHz @ IkHz TEC 61000-4-6 
EFT 2kv 
Comms to ground CO ee 
Surge 2kv 
Comms to Soin TEC 1000-45 
Magnetic field (50/60Hz) 30A/m, 1 min. TEC 61000-4-8 
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8-9.2 
8-9.2.1 


Copper Media 
Copper Media Attachment (Normative References) 


A copper media attachment to an EtherNet/IP network shall support shielded and unshielded 
twisted pair technology. The specifications shall contain enhancements (where needed) based 
on ANSI/TIA/EIA-568-B.1 category Se cabling performance levels minimum. The signaling 
and coupling of these variants shall comply with the requirements of IEEE 802.3, 2005 Ed/TP- 
PMD standard subject to the deviations listed in this section 8-9.2.4. Likewise, the cable’s 
electrical mechanical and environmental performance shall be as defined in section 8-4. The 
TEEE 802.3 standard defines many internal interfaces within the physical layer. EtherNet/IP 
products need not directly implement each of these interfaces, but shall behave as if these 
interfaces exist. These interfaces may be internal to the node and possibly internal to a 
semiconductor device. 


This standard supports 1OBASE T and 100BASE TX copper variants as defined by IEEE Std 
802.3, 2005 Ed. and the ANSI X.3.263 TP-PMD. Two pair cabling does not support 1|OOBASE- 
T4 and is infrequently used, therefore 100BASE-T4 is not supported by this standard. 


Active devices shall be fitted with one of the jacks defined by this chapter. Attached cables 
with flying leads or flying leads with jacks are not allowed. 
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8-9.2.2 Copper Cabling Commercial and Industrial 


The cable is critical in influencing the performance of the network in the presence of high 
noise. To support industrial information and industrial control systems two basic cable types 
(Commercial and Industrial EtherNet/IP Cables) are recognized. Only cables adhering to this 
specification will be eligible for the appropriate conformance check mark. 


Cables shall conform to the specifications table below. 


Table 8-9.3 Minimum Cable Requirements for Commercial and Industrial cabling 


Industrial EtherNet/IP Cable Specifications and Requirements 


Specification Type 


Electrical 


Shielded 


Unshielded 


Conductors 


2 or 4 pairs + Shield 


2 or 4 pairs 


Attenuation Solid 
Conductors 


ANSI/TIA-EIA 568-B.2 Cat Se Horizontal 


ANSI/TIA-EIA 568-B.2 Cat Se Horizontal 


Attenuation Stranded 
Conductors 


ANSI/TIA-EIA 568-B.2 Cat Se Patch | 


ANSI/TIA-EIA 568-B.2 Cat Se Patch ! 


Impedance (fitted) ASTM. 
4566 


95-110 Q 1-4 MHz 
95 — 107 Q 4-100 MHz. 


95-110 Q 1-4 MHz 
95 — 107 Q 4-100 MHz 


RL (dB) 


1-10 MHz 20 + 6Logyo(f) 
10-20 MHz 26 
20-100 MHz 26-5*Logo(f/20) 


1-10 MHz 20 + 6Logio(f) 
10-20 MHz 26 
20-100 MHz 26-5*Logo(f/20) 


NEXT Loss (dB) 


ANSI/TIA-EIA 568-B.2 Cat Se 


ANSI/TIA-EIA 568-B.2 Cat 5e 


Coupling Attenuation (dB) Freq El E2 E3 
(MHz) See Table 8-9.5 ue 

Shielding Effectiveness tbd n/a 
Capacitance unbalance <= 150pf/100meter <= 150pf /100meter 
DCR 9.38 Q/100 meters 9.38 Q/100 meters 
DCR Unbalance 3% 3% 
TCL Frequency El E2 E3 

n/a (MHz) 

See Table 8-9.4 
ELTCTL Frequency El E2 E3 
(He) See Table 8-9.5 
Mechanical Shielded Unshielded 
Pulling Tension 111N 111N 
Breaking Strength 400 N 400 N 
‘Bend Radius [1 at -20€ 1" at -20C 
Dimensional Shielded Unshielded 

(Recommended for RJ 45 
compatibility) 
Jacket OD 0.315" Max 0.315" Max 
Insulated Conductor 0.048" Max 0.048" Max 


1 The insertion loss is based on COMMERCIAL cables. Other constructions, such as high flex, may have different 
performance. Consult the manufacturer for more information. 


— 8-10- 
Edition 1.18 


SINGLE SUBSCRIPTION ONLY; SUBSCRIPTION TERMS AND CONDITIONS OUTLINED ON PAGE (iii) 


Volume 2: EtherNet/IP Adaptation of CIP, Chapter 8: Physical Layer 


8-9.2.2.1 Cabling Balance 


8-9.2.2.1.1 | Unshielded twisted pair transverse conversions loss (TCL) and equal level 
transverse conversion transfer loss (ELTCTL) 


Each pair of unshielded twisted-pair channels shall meet the TCL requirements of Table 8-9.4 
and ELTCTL requirements of Table 8-9.5 below. TCL and ELTCTL shall be measured in 
accordance with ANSI/TIA/EIA-568-B.2-9. 


Table 8-9.4 TCL Limits for Unshielded Twisted Pair Cabling 


fe Rrequency Minimum TCL (dB) ISO/IEC 24702 
ategory | (MHz) E, E Ey 
5 1<f<30 53-15log(f), (40 max) 63-15log(f), (40 max) 73-15log(f), (40 max) 
ca 30<f< 100 60.4 -20log(f) 70.4 -20log(f) 80.4 -20log(f) 


Table 8-9.5 ELTCTL Limits for Unshielded Twisted Pair Cabling 


ae ieee Minimum ELTCTL (B) ISO/IEC 24702 
aNegory | (MHz) E E 7 
Seand6 | 1<f<30 30-20log(f) 40-20log() 50-20log(f), (40 max) 


8-9.2.2.1.2 Shielded Twisted Pair Coupling Attenuation 


Each pair of screened twisted-pair channels shall meet the coupling attenuation requirements of 


Table 8-9.6. 
Table 8-9.6 Coupling Attenuation for Screened Twisted Pair Cabling 
Cat Frequency Minimum Coupling Attenuation (dB) ISO/TEC 24702 
vategol 
Bory | (MHz) E E, E3 
Se 30<f<100 40 50 60 
6 30<f<250 80-20og(f) 90-20log() 100-20Log(*) 
(Max 40 dB) (Max 50 dB) (Max 60 dB) 


Note for EMC purposes, coupling attenuation should be measured up to 1 GHz 
Coupling attenuation shall be measured in accordance with IEC 61156-5 
8-9.2.2.1.3 Two and four pair color codes 


Two and four pair cable color codes shall be as defined Table 8-9.7 and Table 8-9.8 in 
respectively 


Table 8-9.7 Two Pair Color Codes 


Pair Assignment Signal Name 2 Pair 
: TX+ White-orange 
Pair | 
TX- Orange 
‘ RX+ White-green 
Pair 2 
RX- Green 
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Table 8-9.8 Four Pair Color Codes 


TIA Pair Signal Name Color 
Assignment 
: TX+ White-orange 
Pair 2 
TX- Orange 
Pair 3 RX+ White-green 
os NA Blue 
Pair 1 i 
NA White-blue 
Pair 3 RX- Green 
ti NA White-brown 
Pair 4 
NA Brown 


1 Not used for 10 Mbps and 100 Mbps TX networks 


8-9.2.3 Connectors 
8-9.2.3.1 Industrial EtherNet/IP Connector RJ-45 Variant 
Attachment to the medium shall be via either of two types of Industrial grade RJ-45 connectors: 


e Non-Sealed industrial RJ-45 EtherNet/IP connector — The RJ-45 EtherNet/IP connector 
shall meet the IEC 60603-7 standard and additional requirements of this chapter. 

e Sealed Industrial EtherNet/IP RJ-45 connector housing — The IP67 sealed industrial 
EtherNet/IP connector housing shall conform to the specifications IEC 61076-3-106. 
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8-9.2.3.1.1 


Sealed and Non-Sealed Industrial EtherNet/IP Connector 


Standard industrial hardened RJ-45 connector shall meet the following specifications: 


Industrial EtherNet/IP Connector Specifications and Requirements 


Specification Type 
Electrical RJ-45-Shielded RJ-45 
Conductors 8 +1 Shield 8 
Insertion Loss ANSI/TIA/EIA-568-B.2 ANSI/TIA/EIA-568-B.2 
Category SE Category SE 
RL ANSI/TIA/EIA-568-B.2 ANSI/TIA/EIA-568-B.2 
Category SE Category SE 
NEXT Loss ANSI/TIA/EIA-568-B.2 ANSI/TIA/EIA-568-B.2 
Category SE Category SE 
Shielding Effectiveness ANSI/TIA/EIA-568-B.2 N/A 
Category SE 
Mechanical RJ-45-Shielded RJ-45 
Gender Plug and Socket Plug and Socket 


Mating Specification 


Contact plating 


CEI IEC 60603-7 
50u inches min. gold over 100u 
inches min. nickel or equivalent 
plating system 


CEI IEC 60603-7 
50u inches min. gold over 
100u inches min. nickel or 
equivalent plating system 


Contact LLCR over life <20mQ <20mQ 
Initial Contact Low Level Contact <=2.5 mQ <=2.5 mQ. 
Resistance 
Minimum contact force 100 grams 100 grams 
Minimum plug retention force | 133. N 133. N 


Contact Life| 


750 insertions and extractions min. | 750 insertions and extractions 


min. 


1 Required when the connector is used as a standalone connector (not in a protective shell) 


The non-sealed connector shall be wired in accordance with the pin/wire assignments in Table 


8-9.9. 
Table 8-9.9 8 Way Modular Connector Pin/Pair Cable Assignment 
PIN Sigua Pin TS68A main Pin TS68B Pair Assignment 
Name Assignment 
1 TXD+ White Green , White Orange : 
Pair 3 Pair 2 
2 TXD- Green Orange 
3 RXD+ White Orange Pair 2 White Green Pair 3 
4 Na! Blue ; Blue ; 
i 7 Pair 1 - Pair 1 
5 NA White Blue White Blue 
6 RXD- Orange Pair 2 Green Pair 3 
7 Na! White Brown ? White Brown ; 
T Pair 4 Pair 4 
8 NA Brown Brown 
1 Not used for 10 Mbps and 100 Mbps Networks 
Both ends of the cable shall be wired the same unless constructing a crossover cable. 
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8-9.2.3.1.2 | Sealed Industrial EtherNet/IP RJ-45 Housing 


The sealing interface shall meet a minimum of IP67 sealing performance as defined in IEC 
60529. The pin/pair wiring of section 8-9.2.3.1.1 applies to the Sealed Industrial EtherNet/IP 8- 
Way modular connector. Cross over cable are allowed within the same connector family. 


The Sealed RJ-45 variant | is based on the IEC 61076-3-106 specification. The following 
sealed jack drawing sufficiently defines the jack to maintain compatibility for mating and 
sealing amongst various vendors who may make one or both parts. The jack may be offered as 
a PCB mount, bulkhead connector and cable end either field installed or manufactured 
assembly. The jack is fully compatible with standard off-the-shelf plugs. 


Figure 8-9.1 Typical Sealed Jack 
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The Sealed RJ 45 variant 1 is based on the IEC 61076-3-106 specification. The following 
sealed plug drawing sufficiently defines the plug to maintain compatibility for mating and 
sealing amongst various vendors who may make one or both parts. The plug may be offered as 
a field installable or manufactured cable assembly. The plug housing will accommodate a 
standard plug as defined by IEC 60603-7 standard with the exception of the locking 
mechanism, which is disabled. 


Figure 8-9.2 Typical Sealed Plug 
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8-9.2.3.1.3 Sealed M12-4 “D” Coding 


The M12-4 “Type D” coding connector is well known and accepted in industrial ethernet 
applications — for more than 20 years it has been the standard for connection of sensors in the 
industry. The connector is defined in Amendment 1 to IEC 61076-2-101, 4-pin “Type D” 
Coding. The 4-pin M12 connector is suitable for use with 2-pair shielded or unshielded 
Ethernet cables only. 


The M12-4 “D” coding connector shall be wired in accordance with the pin/wire assignments 
in Table 8-9.10. 


Table 8-9.10 M12-4 "D" Coding Cable Pin/Pair Cable Assignment 


PIN Signal Name Color Code Pair Assignment 
1 TXD + White Orange : 
Pair 1 
3 TXD - Orange 
2 RXD + White Green 
Pair 2 
4 RXD- Green 


Construction of crossover cables and conversion cables is permissible. Conversion cables 
constructed with 4-circuit M12-4 “D” coding connectors to 8-Way modular connectors shall be 
constructed from 2 pair cables containing the wire color codes defined in Table 8-9.10. The 
use of a 4 pair cable with 4 position M12-4 “D” coding connector is not permissible. 


The 4-Pin M12 connector is suitable for use with 2 pair shielded or unshielded Ethernet cables 
only. 


Figure 8-9.3 Plug Side and Jack Side Mating View 


Note: 
“D” Coding Keyways 


hs Pair 2 


M12-4 “D” Coding M12-4 “D” Coding 
Plug Jack 
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8-9.2.3.1.4 Sealed M12 X-coding 


The M12 X-coding connector is based on the well-known and industry-accepted M12 
connector technology. This connector is suitable for Ethernet data transmission up to 1 Gigabit 
per second. The connector shall be compliant with the definition of IEC 61076-2-109. For 
conformance to Gigabit applications, this M12 connector shall be used with 4-pair shielded or 
unshielded Ethernet cables only. The connector performance shall meet the minimum 
requirements of the ISO/IEC 11801 Category 6A. The connector shall be compliant to both 
IP65 and IP67 ingress ratings at a minimum. 


Figure 8-9.4 Representation of the PCB-Jack with X-coding and the M12 X-coding Plug 


The M12 8poles X-coded connector shall be wired in accordance with the pin/wire assignments 
in Table 8-9.11. 


Table 8-9.11 Sealed M12-8 X-Coding pin/pair designation and color coding for balanced cabling 


PIN Pin Assignment T568B Pair Assignment aint ere fee au eA 

1 White Orange 2 White Green 3 

2 Orange Green 

3 White Green A White Orange 5 

4 Green Orange 

5 White Brown a White Brown 4 

6 Brown Brown 

7 White Blue 1 White Blue i 

8 Blue Blue 

The wiring conventions T5S68A and T568B are defined in standard TIAS68 Series standards 

Construction of conversion cables is permissible. Conversion cables constructed with M12 X- 
coding connector to 8-Way modular connectors shall be constructed from 4 pair cables 


containing the wire color codes defined in Table 8-9.11. 


Construction of crossover cables between T568A and T568B is permissible. Table 8-9.11 
should be used as reference. 


The use of a 4 pair cable with 4 position M12-4 “D” coding connector is not permissible. 
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8-9.2.3.2 


8-9.2.3.3 


Figure 8-9.5 Plug Side and Jack Side Mating View with pin assignment 


Connector with male pin contacts Connector with female socket contacts 


Mixing 2 and 4 Pair Cabling Components in a Channel 


Cords using multi family connectors are permissible provided the number of conductors in the 
cable is equal to the minimum contact number of connector of the least contact assignment. 
For example, 4 pair cables shall not be used in the same channel with M12-4 “D” coding 
connectors. An exception to this requirement is where the unused pairs of active channel are 
terminated at their characteristic impedance. If terminated, a differential termination without 
reference to ground is preferred. Figure 8-9.6 shows the concept of terminating the un-used 
pairs of active channels in a 4 pair cable. The use of terminal strips is not recommended and is 
only here for illustration. Termination is required at both ends of the active cable where the 
pairs are not used. 


Figure 8-9.6 Example of termination of un-used pair (for reference only) 


Blu 
BIuWh 
un-used pairs 
Bm/Wh 
8m 


Coupler 


A coupler consists of two closely spaced (less than 10cm) electrically connected interfaces. 
Both interfaces are of the same physical mating interface. 


A mated coupler shall conform to the transmission requirements of one connection of the 
appropriate media and category. 


If the interfaces are not electrically close or the coupler does not meet the transmission of the 
appropriate media and category, then the coupler shall be counted as two mated connections. 
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8-9.2.3.4 


8-9.2.3.5 


Adapter 


An adapter consists of two closely spaced electrically connected interfaces. They may be of 
different circuit counts. Both interfaces may be of the same or different physical mating 
interface; for example an M12-4 “D” coding connector to a RJ-45. 


A mated adapter shall conform to the transmission requirements of one connection of the 
appropriate media and category. 


If they not electrically close or the adapter dose not meet the transmission of the appropriate 
media and category, then the adapter shall be counted as two mated connections. 


Bulkhead Connectors 


Bulkhead connectors are typically used at environmental or enclosure boundaries to facilitate 
connection and disconnection to the enclosure. A term used to define a mounting style of 
connectors. Bulkhead connectors are designed to be inserted into a panel cut-out from the rear 
(component side) or front side of the panel. The connector should be used where cables enter or 
exit the cabinet to maintain enclosure seal integrity. In addition they may be used to construct 
modular systems whereby providing modular connectivity. 


Bulkhead connectors allow systems to be designed and built in modular configurations. This 
method should be considered based on user design and service preferences. Modularity 
provides quick deployment and ease of serviceability. 


The designer shall be aware of metallic bulkhead feed throughs that connect the cabling at the 
enclosure wall. This may form a ground loop that could disrupt communications. Where a 
ground loop may be formed, a separate grounding conductor should be installed to provide an 
equal potential between the two points. An alternative method would be to isolate the bulkhead 
feed through using an insulator between the bulkhead feed through and the enclosure wall. 


The transmission performance requirements for a bulkhead connector are defined in section 8- 
9.2.3.5. Figure 8-9.7 is an example of M12-4 D-coding EtherNet/IP bulkhead feed through 
connectors. 


Figure 8-9.7 M12-4 to 8-way Modular Bulkhead 


Consult the manufacturer’s data sheet for mounting hole cut out dimensions. Consider the 
panel minimum and maximum wall thickness of the enclosure when selecting a bulkhead. 
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8-9.2.3.6 
8-9.2.3.6.1 


Industrial Channel Length 
Patch Cord Length 


EtherNet/IP specifications limit the channel to 100 meters or up to 90 meters horizontal wiring 
with two 5-meter patch cords. Some applications will require longer patch cords. In these 
applications the total length of horizontal wiring must be adjusted to compensate for the added 
loss of each connector pair and additional patch cord length beyond 10m. 


C= (102 — H) qd) 
(1+ D) 
Where: 


C is the maximum combined length (m) of the work area cable, equipment cable, and patch 
cord. 


H is the length (m) of the horizontal cable (H + C </= 100 m). 


D is a de-rating factor for the patch cord type (0.2 for 24 AWG UTP/24 AWG ScTP and 0.5 for 
26 AWG ScTP). The de-rating factors are based on COMMERCIAL cables. Other 
constructions, such as high flex, may have different performance. Consult the manufacturer for 
more information. 


W is the maximum length (m) of the work area cable 
T is the total length of horizontal, patch and equipment cords. 


The maximum stranded cable length is limited to 85m for the channel with the standard 20% 


derating for standard stranded cables. 
Table 8-9.12 Wire Type versus Length 
D H Ww Cc T 
Total Total length of 
Patch Horizontal Length patch, 
Cable Length, Patch and equipment and 
Gauge | Patch Derating | (H+C<=100 m) Patch Length | Equipment horizontal 
#24 0.2 100 1) 0 100 
#24 0.2 0 80 85 85 
#24 0.2 25 59 64 89 
#24 0.2 50 38 43 93 
#26 0.5 0 63 68 68 
#26 0.5 25 46 Sl 76 
#26 0.5 50 30 35 85 
#26 0.5 100 0 0 100 
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8-9.2.3.6.2 


Channel Length Based on Temperature 


Elevated temperatures cause higher signal loss in copper cables due to increased resistance. 
This added loss must be considered in addition to the type of copper cable (solid conductor 
horizontal or stranded conductor patch) to determine the maximum channel length. Shielded 
(STP) copper cable typically exhibit 0.2% attenuation increase for every 1° C temperature rise 
above 20° C to 60° C. Unshielded (UTP) Category Se cables typically exhibit 0.4% attenuation 
increase for every 1° C temperature rise from 20° C to 60° C. Unshielded (UTP) Category 6 
cable exhibit 0.4% attenuation increase for every 1° C temperature rise from 20° C to 40° C 
and 0.6% attenuation increase for every 1° C temperature rise from 40° C to 60° C, due to more 
copper and plastic content. The elevated temperature insertion loss is based on 
COMMERCIAL cables. Other constructions, such as high flex, may have different 
performance. The change in attenuation with temperatures beyond 60° C is product specific. 
Consult your supplier for more information. 


The channel length and attenuation are linearly related, that is a 12% increase in attenuation 
reduces the channel length 12%. The following examples show how to calculate the maximum 
channel length for a given configuration and temperature. 


AElev.Temp.=A Increase Coefficient * A T 
LElev.Temp.=AlIncrease Coefficient * A T 
Where: AElev.Temp = elevated temperature attenuation 
Alncrease Coefficient = attenuation temperature coefficient 
A T =change in temperature 
LElev.Temp = elevated temperature maximum length 
Assume you want to use solid conductor, Category Se, horizontal cable at 60° C. 


Note: The entire length should be treated as if the temperature is the worst-case temperature to 
ensure a conservative, simplified calculation. 


You are limited to 100 meters based on the cable type. This distance must be de-rated to 
accommodate the elevated temperature. 60° C is 40° C above 20° C. 40° C times 0.4% equals 
16% length reduction. The length reduction is calculated by taking the percent reduction times 
the cable type length limit: 16% x 100 meters = 16 meters. 


The maximum channel length is calculated by subtracting the elevated temperature length 
reduction from the cable type channel limit: 100 meters — 16 meters = 84 meters. The 
maximum channel length for all solid, horizontal Cat 5e cable at 60° C is 84 meters. 


For all stranded conductor patch Cat 5e at 60° C we have the following: 
Cable type channel limit= 85 meters 
Temperature change = 40C 
Temperature coefficient = 0.4% 
Total change = 16% 
Length reduction = 13.6 meters 


Maximum channel length for all stranded, patch Cat 5 at 60° C is 68.7 meters. 
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8-9.2.3.7 


8-9.2.3.8 


For 25 meters solid, horizontal Cat 5e cable with some length of #24 AWG, stranded 
conductor, Cat Se patch at 40° C we have the following: 


e 25 meters of solid, horizontal cable at 40° C has the loss of 8% more length of cable, 25 x 
1.08 = 27 meters effective length 

e Based on 27 meters we can have the effective length of patch as, (102-27)/(1+0.2)=62.5 

e =Total effective maximum stranded, patch length = 62.5 meters 

e 62.5 meters of stranded, Cat Se patch has 8% more loss then the actual length at 20° C, 
62.5/1.08 = 57.9 meters actual length. 

e The actual maximum stranded length = 57.9 meters 

e The total channel length limit is the sum of the actual solid, horizontal cable maximum 
length limit plus the actual stranded, patch cable maximum length limit, 25 + 57.9 = 82.9 
meters 

e The maximum channel length limit for 25 meters of solid conductor, horizontal Cat 5e 
cable is 82.9 meters at 40° C with a maximum of 57.9 meters of stranded conductor, Cat 5e 
patch cable. 


Industrial Permanent Link 


The length of a industrial permanent link is limited to that of 8-9.2.3.6 less the equivalent 
length of 10 meters of patch cords. 


Number of connections in a channel: 


The number of mated connections allowed in a channel is determined by the desired channel 
performance (Category) and the performance level of the components selected. A Mated 
Connection is defined as an electrically conductive communications path comprised of a mated 
jack and plug. Back to back jack bulkheads may be counted as one connection provided they 
meet the requirements of this chapter. Cable lengths between connecting hardware greater than 
10cm shall be counted in the total channel/link appropriate cable length budget. 


Alternate configurations should be field tested to ensure adequate performance. Table 8-9.13 
provides guidance for connector cable performance levels to achieve a given category channel 
for more than 4 connections. 


Table 8-9.13 Number of allowable Connections in a Channel 


Desired Channel Number of Mated Category Category cable 
performance connections connector (required) 
(required) 
Se 6 6A Se 


Current studies show that: 


a) A Category Se channel topology can include up to 6-mated connections, where each mated 
connection meets minimum Category 6A performance. 


b) Maximum distance between jack and jack of the bulkhead connection is 10 cm. If the 
distance is greater than 10 cm each plug/jack interface shall be considered as a separate mated 
connection. 


In order to maintain Category Se performance in the channel for more than 4 mated 
connections, Category 6A connections shall be used. See Table 8-9.14 for return loss and 
NEXT, transmission requirements for construction of higher count channels. 
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Table 8-9.14 Transmission Requirements for More Than 4-connections in a Channel 


Desired Number of Required Minimum Required Minimum Cable 
Channel Connections Connecting Hardware Connecting Hardware Category 
Class Return Loss (dB) NEXT (dB) 
Se Sor6 26-20 log(f/100) 54-20log(f/100) CAT Se 


8-9.2.3.9 Bulkhead Feed Through and Cable Glands 
8-9.2.3.9.1 | Bulkhead Cable Glands 


Bulkhead cable glands provide entry/exit passages for permanently installed cables. Bulkhead 
feed troughs and/or bulkhead connectors allow systems to be designed and built in modular 
configurations. This method should be considered based on user design and service 
preferences. Modularity provides quick deployment and ease of serviceability. 


8-9.2.3.9.2 | Channels Using Balanced Cabling Bulkhead Connections 


Figure 8-9.8 shows an intermediate cabling channel and a floor distribution channel created 
using a fixed cable terminated at a closure bulkhead. 


The length of the fixed cable used within a channel shall be determined by the equations shown 
in section 8-9.2.3.6. 


In section 8-9.2.3.6, it is assumed that; 


a) The flexible cable within these cords has a higher insertion loss specification than that used 
in the fixed cable, 


b) The cables within these cords in the channel have a common insertion loss specification. 


The maximum length of the fixed cable will depend on the total length of cords to be supported 
within a channel. During the operation of the installed cabling, a management system should be 
implemented to ensure that the cords used to create the channel conform to the design rules for 
the floor, building or installation. 
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Figure 8-9.8 Channel Configurations 
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8-9.2.4 


Industrial EtherNet/IP TP-PMD (Normative References) 


A device that connects to the Industrial EtherNet/IP copper media shall conform to IEC 802.3 
and ANSI X3.263 TP-PMD standard unless noted in this subclause. 


The impedance at the media interface shall conform to ISO/IEC 802.3 (ANSI/IEEE Std 802.3) 
and IEEE Std 802.3u-1995 supplement with the exception of impedance tolerance. The 
temperature range and vibration shall be consistent with the targeted environment. In some 
cases it may be necessary to add components to protect the PMD from surge, ESD, EFT and 
conducted noises. Figure 8-9.12 is an example of how protection devices may be used to 
protect the EtherNet/IP device. In order to maximize the performance in noise, it is critical that 
the components selected for the PMD provide key characteristics. The transformer should 
(highly recommended) provide a minimum of 59dB common mode rejection (CMR) at 30 
MHz. In addition special care in the circuit board trace parameters is needed to maintain 
impedance and noise immunity. Figure 8-9.9 is an example layout showing ground planes and 
isolation areas to help maintain noise immunity. 


Figure 8-9.9 Example Reference Circuit Board Layout (informative) 


0.08" 
Optional 
0.01uF/SOOV 
= z= 1.MOhm 1/4W 


A copper media attachment to an EtherNet/IP network shall support shielded and unshielded 
twisted pair technology. Active interfaces shall be compatible with ANSI/TIA/EIA-568-B.1 
category 5e cabling system and cabling/component enhancements specified by this chapter. 
The signaling, encoding and coupling of these variants shall comply with the requirements of 
IEEE 802.3/TP-PMD and ANSI X3.263 TP-PMD standard subject to the deviations listed in 
this chapter. Likewise, the cable’s electrical mechanical and environmental performance shall 
be as defined in section 8-9.1. The environmental classifications that support this requirement 
is defined the MICE table as defined by IEC 24702. The IEEE 802.3 standard defines many 
internal interfaces within the physical layer. EtherNet/IP products need not directly implement 
each of these interfaces, but shall behave as if these interfaces exist. These interfaces may be 
internal to the node and possibly internal to a semiconductor device. 


At a minimum active interfaces shall support IOBASE T and 100BASE TX as defined by IEEE 
Std 802.3, 2000 Ed. and the ANSI X.3.263 TP-PMD. Two pair cabling will not support 
100BASE-T4 therefore 100BASE-T4 interfaces are not supported by this standard. 
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8-9.2.4.1 Network Jacks for Active Devices 


Active devices are end devices such as computers, sensors and HMIs. These devices generally 
support single network connections unless redundant. An active device with an embedded 
switch shall support AutoMDIX on its ports and be wired in accordance with this sub chapter. 
Repeaters should default to MDIX mode when AutoMDIX or Auto Negotiation is disabled. 
Active devices shall be fitted with one of the jacks defined in this chapter. Attached cables with 
flying leads or flying leads with jacks are not allowed. The jacks for active devices shall be 
wired in accordance with the pin definition described in Table 8-9.9 and Table 8-9.10. 


8-9.2.4.2 Network Jacks for Connectivity Devices (repeaters) 


Connectivity devices are active devices used to control the flow of data throughout the 
infrastructure. For example connectivity devices are classified as repeaters, switches, routers 
and bridges. These devices may have one or more of the following ports, LAN, WAN, Uplink. 
Figure 8-9.10 shows the relationship between LAN and WAN/Uplink ports for connectivity 
and active devices. Connectivity devices such as Switches, routers and bridges shall be fitted 
with jacks. The LAN side of the connectivity devices shall be wired in accordance with Table 
8-9.15 and Table 8-9.16 or provide AutoMDIX. If the connectivity device supports 
AutoMDIX, then it shall default to MDIX state when AutoMDIX is disabled. WAN ports 
including uplink ports shall be wired in accordance with Table 8-9.9 and Table 8-9.10. 


Figure 8-9.10 Port Identification 
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8-9.3 


Table 8-9.15 8-Way Modular Jack Pin Assignment for LAN Ports 


PIN 


Signal Name 


RXD+ 


RXD- 


TXD+ 


Na! 


Na! 


TXD- 


NA! 


wlrafalulalwlro}— 


Na! 


Table 8-9.16 M12-4 "D" Coding Jack Pin Assignment for LAN Ports 


PIN 


Signal Name 
1 RXD + 
3 RXD - 
2 TXD+ 
4 TXD - 


Termination for a 10/100 Mbps Interface with 4 Pair Support 


Active devices shall use an appropriate termination technique such as found in Figure 8-9.11 
for both the used and unused pairs. The unused pairs shall be terminated into their 
characteristic impedance at the device to prevent reflections of coupled energy. A common 
mode termination shall be used to terminate the TXD and RXD pairs. The resistor values may 
be adjusted between 50Q and 75Q to obtain 100Q differential impedance and the appropriate 
common mode impedance. 
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Figure 8-9.11 PHY of Termination Example 
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Figure 8-9.12 Example Physical Layer Block Diagram (informative) 
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8-9.4 
8-9.4.1 


8-9.4.2 


8-9.4.3 


Shield Grounding 
Connectivity Device (Switch, Hub, Bridges, Routers, etc.) 


The communications shield shall be terminated directly to earth ground in accordance with 
TEEE 802.3. 


Two Port Devices 


Two port devices that provide two active ports should not use ganged RJ 45 jacks with 
common shields; doing so will propagate the grounds and potentially cause ground loops in the 
system. Termination of the shield shall be in accordance with Active Devices. 


Active Devices (sensor, PLC etc.) 


To prevent ground loops caused by shielded cables, devices shall not connect the shield directly 
to ground. Industrial EtherNet/IP devices shall provide shield terminated as detailed in Figure 
8-9.13. For Commercial active devices where the shielded RJ 45 connector provides direct 
ground, the shield should be disconnected at the active device end of the channel as shown in 
Figure 8-9.14 and Figure 8-9.15. 


The shield termination for Industrial EtherNet/IP active devices, using a parallel resistor and 
capacitor is shown in Figure 8-9.13. 


Figure 8-9.13 Shield Termination for Devices 
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If the active device provides direct connection to ground through the RJ-45 connector, then the 
shield shall not be connected at the RJ45 plug. Figure 8-9.14 and Figure 8-9.15 are examples of 
how to break the shield at a device that is directly grounded. 


Figure 8-9.14 Example Shield Termination 
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Figure 8-9.15 Shield Termination for Commercial Devices 


Open Shield Connection Shield Connection a 
8-9.5 Fiber Media Variant 
8-9.5.1 Cables 
The following fiber optic cables are supported by this standard: 
Table 8-9.17 Recognized Fiber Cables 
Fiber Type Supported Fiber Wavelength (typical) 
Multimode 50/125um, 62.5/125um 1310 nm 
Singlemode 9/125 um 1310 nm 
Step Index Multimode 1,000 um 650 nm 
8-9.5.1.1 Multi Mode Fiber Optic Cables 
The following multimode fiber optic cables are in accordance with ANSI/TIA/EIA 568-B.3. 
e §62.5/125um 
e =50/1254m 
8-9.5.1.2 Single mode fiber optic 9/125um 
The single mode fiber shall conform to ANSI/EIA/TIA 568-B.3 standard. 
8-9.5.1.3 Step Index Multimode 1mm Polymer Optical Fiber (POF) 


The 1mm POF optical performance and mechanical dimensions of the bare fiber shall conform 
to requirements of IEC 60793-2-40 Ed2 for category A4 fiber at its minimum requirements. 
There are two fiber numerical apertures (NA) recognized by this standard as defined below in 
Table 8-9.16 for A4a.2 and A4d requirements and category. The Imm POF jacketed cables 
shall conform to IEC 60794-2-42 Ed1. Simplex and multicore fiber cables are supported by 
this standard. 


Table 8-9.18 Multimode, POF, Imm Cable Specifications 


Fiber F Fiber cable Fiber mechanical 
Fiber NA ae Sev 
Category specification specification 
Ada.2 1mm POF 0.5 NA TEC 60794-2-42 Ed] IEC 60793-2-40 Ed2 


Add 1mm POF 0.3 NA TEC 60794-2-42 Ed1 IEC 60793-2-40 Ed2 
Note: Mixing of numerical apertures within the same channel is not recommended. 
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The following figures show a channel with no bends and a channel with multiple bends. 


Figure 8-9.16 Maximum Channel Lengths 


Permissible channel length according to Table 8-9.17 A,B 


100BaseFX 
1mm POF 
650nm 


Fiber bend (25mm radius) _ Fiber bend (25mm radius) Fiber bend (25mm radius) 


72 o_S-4 


Permissible channel length according to Table 8-9.18 and 8-9.19 


The number of bends within the channel will reduce the allowable channel length. The channel 
length shall not exceed the lengths shown in the following tables for the number of bends in the 
channel. The following tables describing the maximum channel lengths are based on worst 
case allowable for number of bends and connections at 25°C. 


Table 8-9.19 1 mm A4a.2 POF 0.5 NA 


Maximum link length with additional Number of connections 
losses due to bend radius and number of (Note 2) 
connections 0 1 2 
Worst Case losses (db) Odb 3db 6db 
# Maximum losses(db)due Maximum length in Meters 
to bend radius (Note 3) (Note 1) 
0 0.00 55 43 32 
sie 1 0.87 52 40 | 29 
Mase 5 0.96 51 40 | 28 
3 1.03 51 40 28 
4 1.06 51 39 28 
5 1.09 51 39 28 


Table 8-9.20 Imm A4d POF 0.3 NA 


Maximum link length with additional Number of connections 
losses due to bend radius and number of (Note 2) 
connections 0 1 9. 
Worst Case losses (db) Odb 3db 6db 
# Maximum losses(db)due Maximum length in Meters 
to bend radius (Note 3) (Note 1) 
0 0.00 65 53 4l 
#Bends |] 0.62 63 51 39 
Hos: 5 0.64 2 50 38 
3 0.67 62 50 38 
4 0.69 62 50 38 
5 0.70 62 50 38 
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8-9.5.2 


8-9.5.2.1 


Notes for Table 8-9.19 and Table 8-9.20: 
Note 1: Fiber loss 


Fiber base loss includes environmental influences mainly from absorption of water (which 
is reversible), and the Launch NA of the source. 


Note 2: Connections 


Bulkhead coupling loss is included in minimum launch power of the transmitter and worse 
case receiver sensitivity. Worst case fiber to fiber loss by a connector is assumed to be 3.0 
dB. Two mated connectors coupled with an adapter make a connection. 


EQep ——fii—i EQP 


cl C2 


Note 3: Bending loss 


Bend loss is measured for the fiber with maximum link length. The above table Bending 

losses at 25mm Radius is used as typical value, 1 bend = 360o. If a bend radius is greater 
than 180 mm it is considered straight with no loss. Other bend radiuses are allowable and 
consult manufacturer’s data sheet for bending losses. 


Connectors 


The fiber media attachment to an EtherNet/IP network shall be limited to the LC, SC, SCRJ, 
ST and Sealed M12 Fiber Connector variants. The signaling and coupling for the fiber types 
shall be as specified in the IEEE 802.3 standard subject to the deviations listed in this section 
(section 8-9.5). The SC and ST connectors are legacy connectors and therefore are allowed by 
this standard, however are not recommended for new designs. EtherNet/IP devices utilizing the 
LC transceivers shall have duplex jacks with center spacing compatible with the FOCIS 
standard of 0.246 inches (6.25mm). Permanently attached fiber pigtails shall not be used. 


EtherNet/IP devices utilizing 100BASE-FX medium dependent interfaces (MDI) shall support 
one of the connectors listed in Table 8-9.21. If the MDI supports POF the MDI shall connect to 
the Medium via SCRJ, Sealed M12 Fiber optic connector or connector-less transceiver. 


Non-Sealed Connectors 


Table 8-9.21 Non-sealed Connector Types and Reference Standards 


Non-sealed connector type Reference Standards 
LC, ST, SC ANSI/TIA/EIA-568-B.3, FOCIS 
SCRJ TEC 61754-24 / EN 50377-6-1 


Note: IEC 61754-24 and EN 50377-6-1 is currently at CDV as of 10/10/08. 
Table 8-9.22 LC, SC, SCRJ and ST Connector Insertion Loss 


Connector Loss at Wavelength 
Fiber Medium 650nm. 1310nm Connector(s) 
9/125um Not supported 0.75 dB max. LC, SC!, SCRJ and ST" 
50/125 4m ~~ Not supported 0.75 dB max. | LC,SC', SCRJ, ST', Circular M12 
62.5/125um Not supported 0.75 dB max. LC, scl, SCRJ, sT', Circular M12 
Imm POF 1.5 dB max Not supported SC, ST and connector-less 


1 ST and SC connectors are not recommended for new designs 
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8-9.5.2.2 Sealed Industrial LC Connectors 


Fiber optic connector designs shall meet the requirements of the corresponding ANSI/TIA/EIA 
(Fiber Optic Connector Intermateability Standard (FOCIS) documents). In the case where the 
LC fiber optic connector is placed into the IP65/67 shell or enclosure whereby the latch is 
defeated, the FOCIS requirements may not be applicable. See Table 8-9.22, LC, SC, SCRJ and 
ST Connector Insertion Loss. 


The following sealed plug drawing in Figure 8-9.17 defines the plug. The plug is fully 
compatible with standard off-the-shelf plugs with the exception of the defeated locking 
mechanism when placed in the Variant 1 housing. The dimensions are expressed in inches 
[mm]. 


Figure 8-9.17 Sealed Plug 


The following sealed outlet/jack drawing in Figure 8-9.18 defines the outlet to maintain 
compatibility for mating and sealing amongst various vendors who make one or both parts. 
The outlet is fully compatible with off-the-shelf fiber optic LC plugs and jacks. The 
dimensions are expressed in inches [mm]. 
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Figure 8-9.18 Sealed Outlet 


8-9.5.2.3 Sealed M12 Fiber Optic Connector 


The sealed M12 Fiber connector is RoHS' compliant with a small-form factor. See Table 8- 
9.23 for environmental, mechanical and optical characteristics. 


Table 8-9.23 M12 Fiber Optic Connector Characteristics 


Characteristic Range 
Operating Temperature -25C to +85C 
Storage -40C to +85C 
Salt Spray 48 hours 
Damp Heat 95% RH at 40C, per IEC 61076-2-101 
IP67 rated M12 housing Based on IEC-61076-2-101 
Flame retardant UL 94V-0 
Durability 100 mating cycles 
Contact Retention 20N 
Cable Retention 80N Max 
Cable Torsion 0.35 Nm +/- 30Deg 
Typical Insertion loss <0.3 dB 
Typical return loss -30 dB 
Multimode fibers 50/125 and 62.5/125 0.9 mm, 1.4 mm 


The panel mount receptacle includes an integrated fiber optic transceiver, with a small form 
factor, package design and simplified assembly. See table 8-19 for transceiver characteristics. 


' Restriction of Hazardous Substances directive. 
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The sealed plug drawing in Figure 8-9.19 defines the plug. The cable plug includes a cable 
sealing strain relief and back shell, for enhanced sealing capability. 


Figure 8-9.19 Connector Mechanical Dimensions (all dimensions in millimeters) 
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The connector shall be supplied with standard LC style 1.25mm ceramic ferrules in accordance 
with grade 2 of IEC 61754-20, as shown in Figure 8-9.20. 
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Figure 8-9.20 Ceramic ferrule details (all dimensions in millimeters) 


32 MAX 


Optical Contact - Ceramic 


8-9.5.2.4 Topology of Sealed M12 Fiber Connector 

Figure 8-9.21 shows how the Sealed M12 Fiber Connector can be connected. The connector 
supports both end device connectivity to a like transceiver and in channel connectivity through 
a bulkhead connector. 


Figure 8-9.21 Sealed M12 Fiber Connection Examples 


Topology Example 1: IP85/67 Enclosure 
M12 Fiber Optic System with Transceiver 
Mi2FO. 
Transceiver 


ies 


MI2F.0. 
‘Connector 


Topology Example 2: (P6SI67 Enclosure 
M12 Fiber Optic System with Adapter 


M12FO 
Feed-Through Adapter 


| ea i 


MI2F.O, 
Connector 


IP20 Connector 
Connector (LC, SC; ete) 


8-9.5.2.5 Sealed Industrial SCRJ Connector Plug 


The SCRJ Fiber optic connector used in the IEC 61076-3-106 Variant | housing shall meet the 
requirements of IEC 61754-24. The plug shall be fully compatible with standard off-the-shelf 
plugs. 
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The following sealed plug drawing in Figure 8-9.22 defines the plug in the X, Y, and Z 
dimensions of the mating face of the Variant | plug housing with the SCRJ insert. All 
dimensions are expressed in mm. Dimensions are defined in the IEC 61076-3-106 _Variant 1. 


Figure 8-9.22 Sealed SCRJ Plug 


co} 


To ensure a proper mating and un-mating of the plug and jack assembly, the X,Y and Z 
dimensions shown in Figure 8-9.22 shall be used to locate the connector in the Variant 1 
housing. In addition the solution covered in the Figure 8-9.23, Figure 8-9.24 and Figure 8-9.25 
or a compatible solution should be used. 


Note that the Variant 1 housing and the SCRJ connectors have independent locking 
mechanisms. 


Figure 8-9.23 Mated Sealed SCRJ Plug, Fiber Deflected to Provide Spare Length 


<2mm deflection 
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Figure 8-9.24 Unmated Sealed SCRJ Plug, Fiber Straightened to Unlock the SCRJ Insert 


fiber straightened 


The sealed plug drawing in Figure 8-9.25 describes a design which provides the mechanism for 
the fiber deflection. The 2 mm fiber deflection accommodates disabling the latching 
mechanism of the IP 20 connection by allowing movement of the outer SCRJ latch housing. 
All dimensions are expressed in mm. 
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Figure 8-9.25 Example Design for the Fiber Deflection 
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Other latching and unlatching solutions that meet the mating compatibility requirements of the 
SCRG in the Variant 1 housing are also allowed for use in an ODVA compliant system. 


The fiber termination technology for the POF fiber to the SCRJ ferrule is not part of this 
specification. Other commercially available termination technologies for POF are allowed and 


must meet the mating compatibility requirements of the SCRJ in the Variant 1 housing for use 
in an ODVA compliant system. 
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8-9.5.2.6 


8-9.5.3 


Sealed Receptacle 


The following sealed receptacle drawing in Figure 8-9.26 defines the X, Y and Z dimensions of 
the Variant | receptacle with SCRJ coupler or transceiver. The SCRJ coupler or transceiver 
maintains full mating compatibility and sealing amongst various vendors who make one or both 
parts. The coupler or transceivers are fully compatible with standard off-the-shelf couplers or 
transceivers. 


The receptacle is fully mating compatible with off-the-shelf fiber optic SCRJ plugs. It also 
accepts the SC plug connector. For testing, servicing and maintenance the latching mechanism 
is in use and the plug connector can be pulled out without tools. When the SCRJ fiber optic 
transceiver or coupler is installed in the IP65/67 Variant | receptacle, the following 
modification of the receptacle is required: 


TEC 61076-3-106 Variant 1 Receptacle housing modification: 


2 cuts in the receptacle housing (see Figure 8-9.26). Top left and top right of the receptacle 
housing as shown in the figure. All dimensions are expressed in mm. All other dimensions are 
as defined in the IEC 61076-3-106 Variant 1. 


Figure 8-9.26 Sealed Receptacle Housing 


23,17 201 


Fiber PMD 


The IEEE 802.3 standard defines many internal interfaces within the Physical Layer. 

EtherNet/IP products need not directly implement each of these interfaces, but shall behave “as 

if’ these interfaces existed. These interfaces may be internal to the node and possibly internal 

to a semiconductor device. There are three media variants supported: 

e 100BASE-LX10 using Single mode silica fibers; 

e 100BASE-FX using multi mode silica fibers; 

¢ 100 Mbps using Multi mode graded index plastic optical fiber, compatible with signaling 
of 1OOBASE-FX. 


Other data rates are possible; however they are outside the scope of this standard and will not 
be compatible with the 100 Mbps fiber optic systems. 
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8-9.5.4 


8-9.5.4.1 


8-9.5.4.2 


8-9.5.4.3 


Fiber Optic Transceivers 


This sub clause details the media specific transceivers for EtherNet/IP networks. Currently 
there are two media types supported, Single mode (SM) and Multimode (MM) fiber types. In 
addition this sub-clause provides details on the Sealed M12 transceiver that currently supports 
multimode fiber media. Future releases of this transceiver will include support for 1mm POF 
and single mode fiber media types. This transceiver is documented here to aid in the 
deployment of this new connector system. 


Single mode 


Fiber transceivers shall conform to IEEE 802.3 for 1OOBASE-LX10 (Ethernet in the First Mile) 
using SM Silica fibers. Additional requirements can be found in ISO/IEC 9314-3 Information 
processing systems-Fiber distributed Data Interface (FDDI)- part 3 Physical Layer Medium 
Dependant (PMD) standards with the exception of the transceiver which provides single mode 
coupling using the same wavelength of 1310nm as the multimode variant. The data rate shall 
be 100 Mbps. 


The optical cabling power budget shall be a minimum of 10 dB. 
Connectors supported (new designs): 


e LC defined in 8-9.5.2.1 
e Sealed LC defined in 8-9.5.2.2 


The SC and ST connectors are allowable, however are not recommended for new designs. 
Multimode 


Fiber transceivers shall conform to IEEE 802.3 for 1OOBASE-FX when using multimode 
fibers. Additional requirements can be found in ISO/IEC 9314-3 Information processing 
systems-Fiber distributed Data Interface (FDDI)- part 3 Physical Layer Medium Dependant 
(PMD) standards. 


The optical cabling power budget shall be a minimum of 11dB. 
Connectors supported (new designs); 


e LC defined in 8-9.5.2.1 
e Sealed LC defined in 8-9.5.2.2 


The SC and ST connectors are allowable, however are not recommended for new designs. 
Transceiver for Sealed M12 
The sealed M12 fiber optic transceiver detail is provided in this sub-clause. 


Dimensional drawing for the Receptacle with the Integrated Transceiver is shown in Figure 8- 
9.27. 
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Figure 8-9.27 Transceiver Details (all dimensions in millimeters) 
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Table 8-9.24 Multimode transceiver characteristics 


Characteristic Value 
Power supply Single 3.3 V 
Differential inputs and outputs PECL / LVPECL 
Sealing level IP67 (mated) 
Signal detect indicator Yes 
Center wave length: 1300 nm 

Min 20 dBm to max -14 dBm coupled into 62.5um 

Output optical power fiber 
Input optical power range: Min 14 dBm to Max -31 dBm 


See Table 8-9.25 and Figure 8-9.27 for the transceiver pin out descriptions 
Table 8-9.25 Pin Out Description 


Pin Nr. Symbol Function 
1 VCCRX | Receiver supply voltage, 3.3 Volt 
Z RX+ Receiver data output, non-inverted, LVPECL 
3 RX- Receiver data output, inverted, LVPECL 
4 GND Ground (Receiver) 
5: sD Signal Detect, LVPECL 
6 RSSI Receive Signal Strength Indicator Output, analog voltage (optional) 
ue RES Reserved 
8 SCL Digital information interface, serial clock (optional) 
9 SDA Digital information interface, serial data (optional) 
i GND _| Ground (Transmitter) 
12 TX- Transmitter data input, inverted, LVPECL 
13 TX+ Transmitter data input, non-inverted, LVPECL 
14 VCCTX | Transmitter supply voltage, 3,3 Volt 
PI Pl Pin for future use only. Do not connect to PCB trace. 
P3 P3 Pin for future use only. Do not connect to PCB trace. 


8-9.5.4.4 Step Index Multimode Transceivers 


The POF transceivers shall conform to the electrical specifications of IEC 62149-6. 


The PMD shall support to IEEE 802.3 for 1OOBASE-FX signaling when using step index multi 
mode fibers (e.g. POF). Additional requirements can be found in ISO/IEC 9314-3 Information 
processing systems-Fiber distributed Data Interface — Part 3 Physical Layer Medium 
Dependant (PMD) standards. 
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9-1 


9-2 


Introduction 


Chapter 9 specifies the standard appearance and behavior of EtherNet/IP diagnostic LEDs, 
basic TCP/IP requirements, defines the Device Level Ring protocol (DLR) for EtherNet/IP and 
identifies RSTP and PRP as protocols supported by some devices in the CIP System 
Infrastructure. 


Data Link Layers 


Though this specification is called “EtherNet/IP”, Ethernet is technically not required. The 
EtherNet/IP protocol may be used on any media that supports the transmission of the Internet 
Protocol. 


NOTE: For example, the EtherNet/IP protocol could be used over FDDI, modem lines (SLIP 
or PPP), ATM, etc. 


When any particular medium is used, it shall be used in accordance to commonly accepted 
standards. In particular, when Ethernet is used, it shall be used as defined by the IEEE 802.3 
specification. 
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9-3 


Requirements for TCP/IP Support 


In addition to the various requirements set forth in this specification, all EtherNet/IP hosts are 
required to have a minimally functional TCP/IP protocol suite and transport mechanism. The 
minimum host requirements for EtherNet/IP hosts shall be those covered in RFC-1122, RFC- 
1123, and RFC-1127 and the subsequent documents that may supersede them. Whenever a 
feature or protocol is implemented by an EtherNet/IP host, that feature shall be implemented in 
accordance to the appropriate RFC documents, regardless of whether the feature or protocol is 
considered required or optional by this specification. The Internet and the RFCs are dynamic. 
There will be changes to the RFCs and to the requirements included in this section as the 
Internet and this specification evolves and these changes will not always provide for backward 
compatibility. 


All EtherNet/IP devices shall at a minimum support: 


Internet Protocol (IP version 4) (RFC 791) 

User Datagram Protocol (UDP) (RFC 768) 

Transmission Control Protocol (TCP) (RFC 793) 

Address Resolution Protocol (ARP) (RFC 826) 

e Internet Control Messaging Protocol (ICMP) (RFC 792) 

e Internet Group Management Protocol (IGMP) (RFC 1112 & 2236) 
e JEEE 802.3 (Ethernet) as defined in RFC 894 


eooeee 


NOTE: Although the encapsulation protocol is suitable for use on other networks besides 
Ethernet that support TCP/IP and products may be implemented on these other networks, 
conformance testing of EtherNet/IP products is limited to those products on Ethernet. Other 
suitable networks include: 


e Point to Point Protocol (PPP) (RFC 1171) 

e ARCNET (RFC 1201) 

e FDDI(RFC 1103) 

NOTE: EtherNet/IP devices are encouraged but not required to support other Internet protocols 


and applications not specified here. For example, may support HTTP, Telnet, FTP, etc. This 
specification makes no requirements with regards to these protocols and applications. 
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9-4 
9-4.1 


9-4.2 
9-4.2.1 


9-4,2.2 


9-4,2.3 


9-4.2.4 


Indicators 
Required Indicators 


A product need not have indicators to be compliant with this specification. However, to be 
compliant with the Industrial Performance Level described in Chapter 8, a product shall 
support both the module status and network status indicators as defined by sections 9-4.2, 9-4.3 
and 9-4.4. 


If a product does support any of the indicators described here, they must adhere to the 
specifications described in this section (section 9-4). 


Two types of status indicators may be provided: 


e One module status indicator; 
e One network status indicator; 


Additional indicators may be present; however, the naming and symbol conventions of the 
standard indicators shall not be employed for other indicators. 


NOTE: Indicators, typically implemented as LEDs, help maintenance personnel to quickly 
identify a faulty unit or media. As such, red indicators are used to indicate a fault condition. 


NOTE: Products are encouraged to have an indicator that displays the state of link (for 
example, link status, tx/rx, collision, etc.) following generally accepted industry practices (as 
used in devices such as switches). 


Common Indicator Requirements 
Applicability of Common Requirements 


The common indicator requirement shall only apply to indicators for which requirements are 
specified in this standard. 


Visibility of Indicators 


Indicators shall be viewable without removing covers or parts from the equipment, except in 
cases where the device must also comply with a conflicting standard (e.g., NAMUR NE44). 


Indicators shall be easily seen in normal lighting. Any labels and icons should be visible 
whether or not the indicator is illuminated. 


Indicator Flash Rate 
Unless otherwise indicated, the flash rate of all indicators is approximately 1 flash per second. 


The indicator should be on for approximately 0.5 second and off for approximately 0.5 second. 
This flash rate specification only applies to the indicators specified in this chapter. 


Indicators at Power Up 


An indicator test is to be performed at power-up. To allow a visual inspection, the following 
sequence shall be performed: 


e Turn first indicator Green, all other indicators off 

e Leave first indicator on Green for approximately 0.25 second 

e Turn first indicator on Red for approximately 0.25 second 

e Turn first indicator on Green 

e Turn second indicator (if present) on Green for approximately 0.25 second 
e Turn second indicator (if present) on Red for approximately 0.25 second 
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9-4.3 
9-4.3.1 


9-4.3.2 


9-4.3.3 


9-4.4 
9-4.4.1 


e Turn second indicator (if present) Off 


Tf other indicators are present, test each indicator in sequence as prescribed by the second 
indicator above. If a Module Status indicator is present, it shall be the first indicator in the 
sequence, followed by any Network Status indicators present. After completion of this power 
up test, the indicator(s) shall turn to a normal operational state. 


Module Status Indicator 
Description 


The indication of module status shall require a single bicolor (red/green) indicator that 
represents the state of the entire product. 


NOTE: A product with more than one communication port would have only one module status 
indicator, but more than one network status indicator (one per port). 


Labeling 
The module status indicator shall be labeled with one of the following: 


“MS”; 

"Mod"; 

“Mod Status”; 
“Module Status”. 


States 


The module status indicator shall be in one of the following states: 


Table 9-4.1 Module Status Indicator 


Indicator state Summary Requirement 
Steady Off No power If no power is supplied to the device, the module status indicator shall be steady 
off. 
Steady Green Device If the device is operating correctly, the module status indicator shall be steady 
operational | green. 
Flashing Green Standby If the device has not been configured, the module status indicator shall be 


flashing green. 


Flashing Red Minor fault Tf the device has detected a recoverable minor fault, the module status indicator 
shall be flashing red. 

NOTE: An incorrect or inconsistent configuration would be considered a 
minor fault. 


Steady Red Major fault | If the device has detected a non-recoverable major fault, the module status 
indicator shall be steady red. 

Flashing Green/ | Self-test While the device is performing its power up testing, the module status indicator 

Red shall be flashing green / red. 


Network Status Indicator 
Description 


The Network Status indicator shall be a bicolor (red/green) indicator that represents the status 
of the EtherNet/IP network interface. Devices with multiple physical communication ports but 
a single IP address shall have a single Network Status indicator (e.g., a 2-port device 
supporting Device Level Ring). Devices that support multiple IP addresses may use a Network 
Status indicator for each IP address interface, or may use a single indicator for all interfaces 
(per the behavior in Table 9-4.2). 
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9-4.4.2 


9-4.4.3 


Refer to Volume 2, Chapter 6 (Device Profiles) for additional information on devices with 
multiple interfaces. 


Labeling 

The network status indicator shall be labeled with one of the following: 
° “NS”; 

e “Net”; 

e “Net Status”; 

e "Network Status". 

States 


The network status indicator states shall be as follows: 


Table 9-4.2 Network Status Indicator 


Indicator state Summary Requirement 

Steady Off Not powered, The device is powered off, or is powered on but with no IP address 

no IP address configured (Interface Configuration attribute of the TCP/IP Interface 
Object). 

Flashing Green | No connections An IP address is configured, but no CIP connections are established, and 
an Exclusive Owner connection has not timed out. 

Steady Green Connected At least one CIP connection (any transport class) is established, and an 
Exclusive Owner connection (defined in Volume 1, Chapter 3) has not 
timed out. 

Flashing Red Connection An Exclusive Owner connection (defined in Volume 1, Chapter 3) for 

timeout which this device is the target has timed out. The network status indicator 


shall return to steady green only when all timed out Exclusive Owner 
connections are reestablished. 

Devices that support a single Exclusive Owner connection shall transition 
to steady green when any subsequent Exclusive Owner connection is 
established. 

Devices that support multiple Exclusive Owner connections shall retain 
the O->T connection path information when an Exclusive Owner 
connection times out. The Network LED shall transition from flashing 
red to steady green only when all connections to the previously timed-out 
O->T connection points are reestablished. 

Timeout of connections other than Exclusive Owner connections 
cause the indicator to flash red. 


hall not 


The Flashing Red state applies to target connections only. Originators 
and CIP Routers shall not enter this state when an originated or routed 
CIP connection times out. 


Steady Red Duplicate IP For devices that support duplicate IP address detection, the device has 
detected that (at least one of) its IP address is already in use. 

Flashing Green | Self-test The device is performing its power-on self-test (POST). During POST the 

and Red network status indicator shall alternate flashing green and red. 


Note: when a single indicator is used to represent multiple IP address interfaces the state of any one interface shall 

be sufficient to modify the indicator state (per the above behavior in the table): 

e Transition to flashing green when any one interface receives an IP address 

e Transition to steady green when a CIP connection is established on any interface (and Exclusive Owner is 
not timed out), 

e — Transition to flashing red when an Exclusive Owner CIP connection times out on any interface 

¢ __ Transition to steady red when any of the interfaces detects an IP address conflict 
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Figure 9-4.1 Network Status Indicator State Diagram 


Power-Up / Reset 
| 


A 


Alternate Flashing Green and Red 


i 
POST complete 
| 
v 


Off 


IP address configured 
| 
¥ 


Flashing Green 


IP address lost e 


CIP connection established 


| 
¥ 


No CIP connections AND 
Exclusive Owner 
not timed out 


Duplicate IP 
address 
Steady Green corrected 
All Exclusive Owners Exclusive Owner (target) 
(target) reestablished timed out 
Ad 
=] Flashing Red Steady Red Duplicate IP 
rt address 
detected 
=O 
Edition 1.18 


SINGLE SUBSCRIPTION ONLY; SUBSCRIPTION TERMS AND CONDITIONS OUTLINED ON PAGE (iii) 


Volume 2: EtherNet/IP Adaptation of CIP, Chapter 9: Indicators & Middle Layers 


9-5 
9-5.1 


9-5.2 


Device Level Ring Protocol 
Introduction 


This section defines the Device Level Ring (DLR) protocol — a Layer 2 protocol that provides 
media redundancy in a ring topology. The DLR protocol is intended primarily for 
implementation in EtherNet/IP end devices that have multiple Ethernet ports and embedde: 
switch technology. The DLR protocol provides for fast network fault detection and 
reconfiguration in order to support the most demanding control applications. 


Since the DLR protocol operates at Layer 2 (in the OSI network model), the presence of the 
ring topology and the operation of the DLR protocol are transparent to higher layer protocols 
such as TCP/IP and EtherNet/IP, with the exception of a DLR Object that provides a 
configuration and diagnostic interface for EtherNet/IP. 


A DLR network includes at least one node configured to be a ring supervisor, and any number 
of normal ring nodes. It is assumed that all the ring nodes have at least two Ethernet ports and 
incorporate embedded switch technology. 


Non-DLR multi-port devices — switches or end devices — may be placed in the ring, subject to 
certain implementation constraints (e.g., no MAC table filtering). Non-DLR devices will also 
impact the worst-case ring recovery time. 


The DLR protocol definition includes a number of aspects: 


e A set of end node behaviors, for ring supervisors and normal ring nodes. 
e Protocol messages and associated state diagrams 
e Implementation requirements for devices 


Supported Topologies 


The DLR protocol supports a simple, single-ring topology; it has no concept of multiple or 
overlapping rings. A network installation may however use more than one DLR-based ring, so 
long as each of the rings are isolated such that DLR protocol messages from one ring are not 
present on another ring. 


The DLR protocol may coexist with, but does not interface with, standard network protocols 
such as IEEE Spanning Tree Protocols (STP, RSTP, MSTP), and also with vendor-specific 
redundancy protocols. That is, users may construct network topologies with DLR protocol 
rings connected to switches that are running Spanning Tree or other ring protocols, as shown in 
Figure 9-5.1. 
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Figure 9-5.1 DLR Rings Connected to Switches 
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In Figure 9-5.1, each DLR ring is a separate DLR network, each with a ring supervisor. The 
supervisors are shown with one port in blocked mode, which is the case when there are no 
faults in the ring. 

The switches to which the DLR rings are connected may run STP/RSTP/MSTP to ensure loop 
free operation when redundant paths are present (indicated by the green lines in Figure 9-5.1). 
Spanning Tree Protocol messages (BPDUs) that are sent by the switch on the DLR ring ports 
will be blocked by the DLR Ring Supervisor, so that the switches do not block the DLR ports 
(refer to Section 9-5.6.4, IEEE 802.1D/802.1Q STP/RSTP/MSTP Considerations). 


Note: The switches’ ports to which the DLR devices are connected must be configured 
properly in order ensure proper functioning of the network (refer to section 9-5.5). 


More complicated topologies combining DLR rings and non-DLR switches running 
STP/RSTP/MSTP may result in DLR ports being blocked in an undesirable manner. Refer to 
section 9-5.5 for additional information. 

DLR supports redundant gateways for connecting with network infrastructure outside of the 
DLR network to the DLR network itself. Refer to section 9-5.8 for additional information. 


-9-11- 
Edition 1.18 
SINGLE SUBSCRIPTION ONLY; SUBSCRIPTION TERMS AND CONDITIONS OUTLINED ON PAGE (iii) 


Volume 2: EtherNet/IP Adaptation of CIP, Chapter 9: Indicators & Middle Layers 


9-5.3 
9-5.3.1 


Overview of DLR operation 
Normal Operation 
Figure 9-5.2 shows the normal operation of a DLR network. 


Figure 9-5.2 Normal DLR Network Operation 
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Each node in Figure 9-5.2 has two Ethernet ports, and is assumed to have implemented an 
embedded switch. When a ring node receives a packet on one of its Ethernet ports, it 
determines whether the packet needs to be received by the ring node itself (e.g., the packet has 
the node’s MAC address) or whether the packet should be sent out the node’s other Ethernet 
port. 


The active ring supervisor blocks traffic on one of its ports with the exception of few special 
frames and does not forward traffic from one port to other. Because of this configuration a 
network loop is avoided and only one path exists between any two ring nodes during normal 
operation. 


Figure 9-5.3 illustrates the use of Beacon and Announce frames sent by the active ring 
supervisor: 


Figure 9-5.3 Beacon and Announce frames 
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9-5.3.2 
9-5.3.2.1 


The active ring supervisor transmits a Beacon frame through both of its Ethernet ports once per 
beacon interval (400 microseconds by default). The supervisor also sends Announce frames 
once per second. The Beacon and Announce frames serve several purposes: 


1. The presence of Beacon and Announce frames inform ring nodes to transition from linear 
topology mode to ring topology mode. 


2. Loss of Beacon frames at the supervisor enables detection of certain types of ring faults. 
(Note that normal ring nodes are also able to detect and signal ring faults). 


3. The Beacon frames carry a precedence value, allowing selection of an active supervisor 
when multiple ring supervisors are configured. 


Link Failures 
Common Failures 
The most common form of link failure includes the following cases: 
1. Link or other physical layer failure recognized by a node adjacent to the failure. 


2. Power failure or power cycling a ring node, recognized by the adjacent node as a link 
failure. 


3. Intentional media disconnect by user to bring new nodes online or to remove existing ones. 


In the above cases, the nodes adjacent to the fault send a Link_Status message to the ring 
supervisor. Figure 9-5.4 shows ring nodes adjacent to a fault sending a Link_Status message to 
the ring supervisor. 


Figure 9-5.4 Link Failure 
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After receipt of the Link_Status message, the ring supervisor reconfigures the network by 


unblocking traffic on its previously blocked port and flushing its unicast MAC table. The 
supervisor immediately sends Beacon and Announce frames with the ring state value indicating 
that the ring is now faulted. 


Ring nodes also flush their unicast MAC tables upon detecting loss of the beacon in one 
direction, or upon receipt of Beacon or Announce frames with the ring state value indicating 
the ring fault state. Flushing the unicast MAC tables at both supervisor and ring nodes is 
necessary for network traffic to reach its intended destination after the network reconfiguration. 
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9-5.3.2.2 


9-5.3.2.3 


9-5.3.2.4 


9-5.4 


Figure 9-5.5 shows the network configuration after a link failure, with the ring supervisor 
passing traffic through both of its ports. 


Figure 9-5.5 Network Reconfiguration after Link Failure 
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Uncommon Failures 


In addition to the more common link failures, there is a class of uncommon failures: 


. Higher level hardware/firmware component(s) on a ring node has failed leading to lost 
traffic, but the physical layer is functioning normally with power supply intact. 


2. A chain of ring protocol unaware nodes are connected between protocol-aware nodes, and 
the failure has occurred somewhere in the middle of this chain. 


In these cases, the ring supervisor will detect the loss of Beacon frames first on one port, and 
eventually on both of its ports. The supervisor will reconfigure the network as described in the 
“Common Failures” section. In addition, the ring supervisor will send a Locate_Fault frame to 
diagnose the fault location (refer to the subsequent section on the Neighbor Check process). 


Partial Network Fault 


It is possible for a partial network fault to occur such that traffic is lost in only one direction. 
The active ring supervisor detects a partial fault by monitoring the loss of Beacon frames on 
one port. When a partial fault is detected the active supervisor blocks traffic on one port and 
sets a status value in the DLR Object. The ring at this point will be segmented due to the 

partial fault, requiring user intervention. 


Rapid Fault/Restore Cycles 


Certain conditions such as a faulty network connector may cause the ring supervisor to detect a 
series of rapid fault/restore cycles. If left to persist, such a condition could result in network 
instability that is difficult to diagnose. When the active supervisor detects the rapid 
fault/restore condition (5 faults in a 30 second period), it sets a status value in the DLR Object, 
and blocks traffic on one port. The user must explicitly clear the condition via the DLR Object. 


Classes of DLR Implementation 


There are several classes of DLR implementation, as described below. Detailed requirements 
for each class of implementation are further specified in subsequent sections. 
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9-5.4.1 Ring Supervisor 


[his class of device is capable of being a ring supervisor. Such devices must implement the 
required ring supervisor behaviors, including the ability to send and process Beacon frames at 
the default beacon interval of 400 microseconds. Smaller beacon intervals, as low as 100 
microseconds, may be supported, but are not required. 


9-5.4.2 Ring Node, Beacon-based 


This class of device implements the DLR protocol, but without the ring supervisor capability. 
The device must be able to process and act on the Beacon frames sent by the ring supervisor. 
Beacon-based ring nodes shall support beacon rates of 100 microseconds to 100 milliseconds in 
order to accommodate all ring supervisor implementations. 


9-5.4.3 Ring Node, Announce-based 


[his class of device implements the DLR protocol, but without the ring supervisor capability. 
In order to accommodate nodes that do not have the capacity to process Beacon frames, ring 
nodes may simply forward, but not explicitly process, Beacon frames. Such nodes must 
process Announce frames. 


9-5.5 DLR Behavior 
9-5.5.1 DLR Variables 


Table 9-5.1 summarizes variables used in the DLR protocol behavior and messages. Refer to 
the subsequent sections on Ring Node and Ring Supervisor behavior and DLR messages for 
further details. The DLR Object (Chapter 5) exposes these variables (with the exception of the 
Node State) via object attributes. 


Table 9-5.1 DLR Variables 


DLR Variable Description 
Node State Internal state of a node’s DLR state machine: 
IDLE_STATE - initial state for non-supervisors, indicating linear topology 
mode. 


FAULT_STATE -~ initial state for enabled ring supervisor, or when ring fault 
has been detected (both supervisor and ring nodes). 
NORMAL_STATE — normal function in ring topology mode. 


Ring State State of the ring network. Transmitted by ring supervisors in Beacon and Announce 
frames: 
RING_NORMAL_STATE - Ring is functioning, with supervisor blocking 
traffic on one port. 
RING_FAULT_STATE - Fault detected, ring supervisor is not blocking traffic 
(also is the initial state transmitted in the Beacon and Announce frames). 


Beacon Interval Interval at which the ring supervisor sends Beacon frames. Supervisors shall support a 
range from 400 microseconds to 100 milliseconds. The default value shall be 400 
microseconds. Supervisors may support a Beacon Interval smaller than 400 microseconds, 
but this is not required. The absolute minimum Beacon Interval is 100 microseconds. 
Beacon-based ring nodes shall support beacon rates of 100 microseconds to 100 
milliseconds in order to accommodate all ring supervisor implementations. 


Beacon Timeout Amount of time nodes shall wait before timing out reception of Beacon frames and taking 
the appropriate action (depending on whether supervisor or normal ring node). 
Supervisors shall support a range from 800 microseconds to 500 milliseconds. The default 
shall be 1960 microseconds. Supervisors may support a Beacon Timeout of smaller than 
800 microseconds but this is not required. The absolute minimum Beacon Timeout is 200 
microseconds. 
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9-5.5.2 
9-5.5.2.1 


9-5.5.2.2 


DLR Variable Description 
Supervisor Precedence value assigned to a ring supervisor, and transmitted in Beacon frames. Used to 
Precedence select active ring supervisor when multiple supervisors have been configured. 
Default value is 0. Can be changed via the DLR Object. 
DLR VLAN ID VLAN ID used when sending DLR protocol frames. The VLAN ID is configured at the 


ring supervisor (via the DLR Object), and is then detected by ring nodes when they 
receive and process the Beacon or Announce frames from the supervisor. 

Default value is 0. Typically the VLAN ID does not need to be changed unless a 
commercial switch is being used in the ring. 


Ring Supervisor 
Startup 


An enabled ring supervisor shall start in FAULT_STATE and configure both ports to forward 
frames. The supervisor shall send Beacon frames out both of its ports, with the Ring State set to 
RING_FAULT_STATE. The supervisor shall also send Announce frames out both of its ports 
with the Ring State set to RING_FAULT_STATE. 


Once the Beacon frames are received through both ports the supervisor shall transition to 
NORMAL_STATE, flush its unicast MAC address table and reconfigure one of its ports not to 
forward packets, except for the following, which shall be forwarded to the host for processing: 


e Beacon frames with the supervisor’s own MAC address (in general needed only for 
software implementations). 

¢ Beacon frames from other ring supervisors. 

e Link_Status/Neighbor_Status frames. 

e Neighbor_Check request or response, and Sign_On: always forward received frames. For 
frames originated by the supervisor, only forward frames with the Source Port matching the 
blocked port. 


Upon transition to NORMAL_STATE, the Ring State in the Beacon frames shall be set to 
RING_NORMAL_STATE. The ring supervisor shall also send an Announce frame out one 
port, with Ring State set to RING_NORMAL_STATE. 


Multiple Ring Supervisors 


When multiple ring supervisors are configured, each supervisor sends Beacon frames when it 
comes online. The Beacon frames carry a supervisor precedence value. When a supervisor 
receives a Beacon frame, it checks the precedence value. If the precedence in the Beacon 
frame is higher than the receiving node’s precedence value, the receiving node transitions to 
FAULT_STATE and becomes a backup supervisor. If the precedence values are the same, the 
node with the numerically higher MAC address becomes the active supervisor. 


The backup supervisors configure their DLR parameters with the values obtained from the 
active supervisor’s Beacon frames: Beacon Interval, Beacon Timeout, VLAN ID. 


The backup supervisors continue to monitor both ports for timeout of the Beacon frames (no 
Beacons received within the Beacon Timeout period). If the Beacon has timed out on both 
ports, the backup supervisor waits for an additional Beacon Timeout period (during which time 
other nodes transition to linear mode), then begins sending its own Beacons so that a new 
supervisor can be selected. 
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9-5.5.2.3 


9-5.5.2.4 


9-5.5.2.5 


9-5.5.2.6 


Sign On 


In order to identify ring protocol participants, the active ring supervisor shall send a Sign_On 
frame when it transitions to NORMAL_STATE. Refer to the Sign_On information in the 
“DLR Messages” section. 

Normal Ring Operation 


When in the NORMAL_STATE, the active ring supervisor shall send Beacon frames out both 
of its ports. It shall also send an Announce frame once per second out one port 


One of the active supervisor’s ports shall be configured not to forward frames, with the 
exceptions as noted in section 9-5.5.2.1. 


Ring Fault Detection 


One of several possible events shall cause the active ring supervisor to transition to 
FAULT_STATE: 


1. Beacon frame received from another supervisor with a higher precedence value. 


2. Loss of Beacon frames on either port for the period specified by the Beacon Timeout, 
indicating a break somewhere in the ring. 


3. Detection of loss of link with the neighboring node on either port. 
4. Link_Status frame received from a ring node, indicating a ring node has detected a fault. 
In all of the cases listed above, the active ring supervisor shall: 


e Transition to FAULT_STATE 

e Flush its unicast MAC address table 

e Unblock the blocked port 

e Send Beacon frame out both ports, with Ring State set to RING_FAULT_STATE 
Send Announce frame out both ports, with Ring State set to RING_FAULT_STATE 


In addition, in case 2 above, the active ring supervisor shall initiate the Neighbor Check process 
by issuing a Locate Fault frame. The supervisor shall also issue its own Neighbor Check frame 
through the port(s) on which the beacon has timed out. 


When in FAULT_STATE the ring supervisor shall continue to send Beacon frames, in order to 
detect ring restoration. 


Ring Restoration 


When the active ring supervisor is in FAULT_STATE, receipt of Beacon frames on both ports 
shall cause a transition to NORMAL_STATE. The active ring supervisor shall do the 
following: 


e Flush the unicast MAC address table 

e Reconfigure its ports such that traffic is not forwarded on one port (with exceptions as noted 
previously) 

¢ Send Beacon frames with the Ring State set to RING_NORMAL_STATE 

e Send Announce frames out one port with Ring State set to RING_NORMAL_STATE 
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9-5.5.2.7 


9-5.5.3 
9-5.5.3.1 


Changing Ring Parameters 
The following ring supervisor parameters may be changed via the DLR Object (see Chapter 5): 


e Supervisor precedence value 
e Beacon interval 

¢ Beacon timeout 

e VLAN ID 

e Supervisor enabled/disabled 


When any of the above parameters are changed on the active ring supervisor, the ring 
supervisor shall cease sending Beacon and Announce frames for two (current) beacon timeout 
periods, then shall send Beacon frames using the new parameters. Ceasing the Beacon frames 
allows beacon-based ring nodes to detect the new parameters when the Beacon is restored and 
triggers active supervisor negotiation based on the new parameters. Announce frame 
production is further suppressed for at least 2 new beacon timeout periods to make sure that the 
active supervisor is determined before any Announce frames with the new parameters are sent. 


When parameters are changed on a backup ring supervisor, the behavior depends on the backup 
supervisor’ s new precedence value compared to the active supervisor’s precedence value: 


e New backup precedence value is greater than the current active ring supervisor’s precedence 
or of equal precedence with numerically higher MAC address than active supervisor MAC 
address: backup shall immediately begin sending Beacon frames with the new parameters. 

e New backup precedence value is less than the active supervisor’s precedence or of equal 
precedence with numerically lower MAC address than active supervisor MAC address: 
modification to the Beacon Interval, Beacon Timeout, and VLAN ID shall be ignored. 


Ring Node 
Beacon VS. Announce-Based Implementations 


Ring nodes (that is, non-supervisor nodes) may have differing implementations depending on 
whether or not they are able to process the Beacon frames which by default are sent every 400 
microseconds (but may be sent as fast as every 100 microseconds). Nodes that are able to 
process the Beacon frames generally have hardware assistance in implementing the DLR 
protocol, so that they don’t burden the device’s CPU with processing the Beacon frames. 


Devices that would need to process the Beacon frames in the device’s CPU can instead 
configure their embedded switch to simply pass the Beacon frames on the network without 
interpretation or further processing. Such devices must however process the Announce frames, 
which also indicate the ring state but are sent at a much slower rate. 


Note that it is possible to implement a Beacon-based node without hardware assistance, 
provided the device’s CPU has sufficient capacity to process the Beacon frames in addition to 
its other required functions. 


It is desirable for device implementations to be Beacon-based rather than Announce-based, 
since better ring recovery performance results when ring nodes are able to process Beacon 
frames. Refer to section 9-5.11, (Performance Analysis). 
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9-5.5.3.2 


9-5.5.3.3 


9-5.5.3.4 


Startup — Beacon-based 


A Beacon-based ring node shall start up in IDLE_STATE, which presumes the network is in 
linear topology mode. 


Upon receiving a Beacon frame through either port, the node shall transition to 


FAULT_STATE, which presumes the ring topology mode. The ring node shall flush its unicast 
MAC address table and save the ring supervisor parameters from the Beacon frame: 


e Supervisor MAC address 

e Supervisor precedence value 
¢ Beacon timeout 

VLAN ID 


Upon receiving Beacon frames through both ports and after receiving a Beacon frame from 
active ring supervisor with ring state field set to RING_STATE_NORMAL on either one of its 
ports, the node shall transition to NORMAL_STATE and flush its unicast MAC address table. 


Startup — Announce-based 


An Announce-based ring node shall start up in IDLE_STATE, which presumes the network is 
in linear topology mode. 


Upon receiving an Announce frame through either port, the node shall transition to the ring 
state indicated in the Announce frame. The ring node shall flush its unicast MAC address table 
and save the ring supervisor parameters from the Announce frame: 


e Supervisor MAC address 
e Ring State 
e VLAN ID 


FAULT DETECTION 
One of several possible events shall cause a ring node to transition from NORMAL_STATE: 
For Beacon-based nodes: 
1. Receipt of a Beacon frame with the Ring State set to RING_FAULT_STATE. 


2. Receipt of a Beacon frame with a different MAC address and higher precedence than the 
current ring supervisor. 


3. Loss of Beacon frames on both ports for the period specified by the Beacon Timeout, which 
causes the node to transition to IDLE_STATE (i.e., the topology is now linear). 


4. Loss of Beacon on a single port for the period specified by the Beacon Timeout. 
For Announce-based nodes: 
1. Receipt of an Announce frame with the Ring State set to RING_FAULT_STATE 


2. Loss of Announce frame for the Announce timeout duration, which causes the node to 
transition to IDLE_STATE (i.e., the topology is now linear). 


In all of the cases listed above, the ring node shall: 


e Flush its unicast MAC address table. 


e Transition to FAULT_STATE (Exception: loss of Beacon on both ports or loss of 
Announce causes transition to IDLE_STATE). 
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9-5.5.3.5 


9-5.5.4 


9-5.5.5 


Ring Restoration 


For ring nodes, the process for ring restoration is the same as the Startup case (see section 9- 
5.5.3.2 and 9-5.5.3.3). 


Sign On Process 


The Sign_On frame is used to identify all ring participants. The active ring supervisor shall 
send a Sign_On frame when it transitions to NORMAL_STATE. The active supervisor 
transmits a Sign_On frame once every one minute while in NORMAL_STATE, until it 
receives a Sign_On that it sent out previously. Upon receiving such a frame the active 
supervisor will cease to send further Sign_On frames until next transition into 
NORMAL_STATE. The collected participant list can be accessed through the DLR Object. 


The Sign_On frame is a multicast message transmitted from one port of the active ring 
supervisor. The receiving ring participant node traps the Sign_On frame and forwards it only to 
the host CPU. The host CPU increments the number of nodes in list, add its own addresses to 
list and transmit the Sign_On frame only through the other port than the receiving port. 


The Sign_On frame is transmitted from one ring participant node to the next in similar fashion 
and eventually reaches the active supervisor. The active supervisor can identify the Sign_On 
Tame it sent out by confirming that the first entry is its own. 


It is possible that the number of nodes in the ring large enough that all nodes’ addresses do not 
it in the Sign_On frame. When a node receives the Sign_On frame, if adding the node’s 
address would exceed the maximum frame size, the node does not add its address, but saves the 
port through which the frame was received and sends the Sign_On frame directly to the active 
ring supervisor. 


When the ring supervisor receives the Sign_On frame sent to its unicast MAC address, it 
assumes this is due to the Sign_On frame size reaching its maximum. The supervisor restarts 
the Sign On process by sending a new Sign_On frame directly (unicast) to the node from which 
it received the unicast Sign_On frame. 


Upon receiving the new Sign_On frame from the ring supervisor, the ring node adds its address 
to the Sign_On frame. The node then sends the Sign_On frame (multicast) through its other 
port than the saved port. 


Neighbor Check Process 


When the active ring supervisor detects the loss of Beacon, it sends a Locate_Fault frame 
through both ports. 


Upon receipt of the Locate_Fault frame, each ring node issues a Neighbor_Check request 
through both of its ports. The supervisor also issues its own Neighbor_Check request. 


When any node receives a Neighbor_Check_Request frame it responds with a 
Neighbor_Check_Response frame through the port on which original request was received. If 
the node sending the Neighbor_Check_Request does not receive a response in 100ms, it shall 
retry the request. After a total of 3 attempts, if no response is received after the overall 300ms 
timeout expires, the node sends a Neighbor_Status frame to the ring supervisor. 
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Figure 9-5.6 Neighbor Check Process 
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Figure 9-5.6 illustrates the Neighbor Check process. In this example, all healthy ring nodes 
respond, while the failed ring node 3 does not. Ring nodes 2 and 4 will each ultimately send a 
Neighbor_Status frame to the ring supervisor. 


DLR Object 


Devices that implement the DLR protocol shall implement the DLR Object, specified in 
Chapter 5. 


Implementation Requirements 
Embedded Switch Requirements and Recommendations 


The following are general requirements and recommendations for all devices that implement 
embedded switch technology (whether implemented via commercially-available chips, FPGA, 
ASIC, etc.): 


e JEEE 802.3 operation: 

e Auto-negotiation, with 10/100Mbps, full/half duplex (Required) 

e Forced setting of speed/duplex (Required) 

e Auto MDIX (medium dependent interface crossover), in both auto-negotiate and forced 
speed/duplex modes. Note: This is a PHY and transformer issue, not an embedded switch 
issue. (Required) 

© QoS: 

e 2 queues (Required); 4 (Recommended) 

e High priority queue for DLR frames, with strict priority scheduling for the high priority 
queue (Required) 

e Prioritization via 802.1Q/D (Required) and DSCP (highly recommended). Usage shall be 
consistent with the EtherNet/IP QoS scheme published in Volume 2. For IP frames the 
embedded switch should use the DSCP value. For non-IP frames the priority in the 
802.1Q header should be used. 

e Broadcast rate limiting for host CPU (Recommended). The broadcast threshold tolerated 
by a device is dependent on the host CPU. As a general recommendation, the broadcast 
rate limiting should be triggered when the broadcast traffic exceeds 1% of bandwidth. 
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e Filtering of incoming unicast and multicast to host CPU (Recommended, but in practice 
most all devices will require this). 


DLR Implementation Requirements 


The following implementation requirements apply to DLR nodes, whether ring supervisors or 
ring nodes: 


e Preserve IEEE 802.1Q VLAN Id and tag priority of ring protocol frames 

e Disable IP multicast filtering on ring ports or flush multicast filtering table of ring ports on 
ring state transitions. 

¢ Configure multicast address for Beacon frames to be forwarded on ring ports, and to the 
host CPU for Beacon-based implementations. 

¢ Configure multicast address for Announce and Locate_Fault frames to be forwarded to the 
host CPU and on ring ports. 

¢ Configure multicast address for Neighbor_Check_Request /Response and Sign_On to be 
forwarded only to host CPU. 

e¢ Mechanism to flag the port through which such a frame was received from ring. 

¢ Mechanism to forward such frames from host CPU on to ring only through the port it was 
intended to go out. 

e Configure unicast MAC address of active ring supervisor so that supervisor frames 
forwarded on both ports 

e Flush unicast MAC address tables on ring state transitions (or disable learning) 

¢ Configure unicast MAC address of self so that it is not purged when MAC address table is 
flushed. 

e Implement the Interface Counters and Media Counters attributes of the Ethernet Link Object 
(see Chapter 5) to aid in network monitoring. 

e Implement the QoS Object with, at a minimum, DSCP marking of EtherNet/IP traffic 
generated by the device (see Chapter 5). 

e Recommended: configure access control list or another suitable mechanism to remove 
device’s own frames from network when received (e.g., during ring startup/restoration) 

e Disable 802.3 and other hardware flow control mechanisms on ring ports 

¢ The 802.3 methods to determine a link’s presence when a port is configured to operate in 
forced speed/duplex mode frequently yield transient link state transitions when a cable is 
inserted. To prevent unnecessary ring state transitions during cable insertion, devices shall 
ensure that the link is stable before enabling frame forwarding to/from the associated port or 
generating a Link_Status frame. This may typically be accomplished by adding some 
debounce (e.g. a delay of 10-100 ms, depending on hardware implementation) to achieve 
stable link transitions. 


TEEE 1588 / CIP Sync Considerations 


In order to support applications requiring time synchronization (e.g., CIP Motion or CIP Sync), 
multi-port devices are recommended to support the following capabilities with respect to IEEE 
1588/CIP Syne: 


e Implement IEEE 1588 end-to-end transparent clock. 

e Devices that also implement 1588 ordinary/boundary clock functionality should perform 
path delay measurement using Delay_Req/Delay_Resp frames whenever the ring state or 
network topology mode changes. 
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e Devices that implement 1588 ordinary/boundary clock functionality and are connected to 
the ring network indirectly should perform path delay measurement using 
Delay_Req/Delay_Resp frames per the ODVA-specific IEEE 1588 profile signaling 
message (refer to the Time Sync Object in Volume 1). 


Devices not implementing these features will suffer from poor synchronization accuracy for 
short periods after a network reconfiguration. 


Refer to the CIP Sync specification in Volume 1 for more information on CIP Sync. 
IEEE 802.1D/802.1Q STP/RSTP/MSTP Considerations 


In order for DLR to coexist with IEEE spanning tree protocols STP, RSTP and MSTP the 
active ring supervisor shall not forward multicast frames with destination address 
01:80:C2:00:00:00 (BPDU frames) from one ring port to other, irrespective of ring state. 
However, if the active ring supervisor has non-ring ports (e.g., in the case of a switch) it shall 
forward said multicast frames between those non-ring ports and only between one ring port and 
those non-ring ports. This behavior shall be implemented to ensure that any loop through the 
ring other than the one through active ring supervisor is detected correctly by 
STP/RSTP/MSTP. 


Using Non-DLR Nodes in the Ring Network 
General Considerations 


The DLR protocol does not, by design, require that all nodes in the ring implement the 
protocol. Non-DLR nodes may be placed in the ring, provided they support certain required 
capabilities as outlined in subsequent subsections. 


The end user should be made aware that using non-DLR nodes in the ring can affect 
performance, lengthening the ring recovery times (see section 9-5.11, Performance Analysis). 
For best performance, it is highly recommended that all nodes in the ring implement the DLR 
protocol. 


Where the use of non-DLR devices cannot be avoided, it is highly recommended that such 
devices be connected to the network via a DLR-aware device such as a 3-port switch (2 ports 
connected to the network, | port connected to the non-DLR device). 


When using non-DLR nodes directly in the ring, certain capabilities and/or configuration steps 
are required of those nodes in order for the DLR protocol to function properly. These 
capabilities and configuration steps are described further in the following sections. 


Non-DLR End Devices 


Examples of non-DLR devices might include an existing 2-port I/O module or drive that 
supports embedded switch technology but has not implemented the DLR protocol. Such 
devices may be inserted directly into the ring network. However in order to ensure proper 
functioning of the ring, the non-DLR end device must have the following capabilities: 


e Disable unicast MAC address learning (or not employ MAC address learning at all). Since 
Beacon frames will arrive on both ports with the supervisor’s MAC address, address 
learning will cause the supervisor’s MAC to bounce from one port to the next. If the 
supervisor is also an I/O device, the I/O communications can be interrupted. 

e Disable multicast filtering on DLR ring ports. If not disabled, multicast messages may not 
be forwarded to other ring nodes. 

e Support reception of 802.1Q frames and preserve VLAN Id and tag priority. DLR messages 
may be dropped if not supported, or not queued properly if tag priority is not preserved. 
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e Implement priority queues with highest priority queue used for DLR messages, with strict 
priority scheduling. If not supported, ring recovery performance may be affected. 


It is the end user’s responsibility to ensure that the non-DLR device supports the above 
capabilities. 


Non-DLR Switches 


It is possible for commercially-available managed Ethernet switches that are not DLR aware to 
be placed directly in the ring. For example, a user may wish to connect a ring of end devices 
into a switch in order to connect the end devices into the user’s larger network. 


In order to simplify the switch configuration, it is advisable to connect the non-DLR switch to 
the ring via a DLR-aware device such as a simple 3-port switch. When the non-DLR switch is 
connected directly into the ring, a number of configuration steps are required. The specifics of 
the configuration steps may vary from vendor to vendor. In general, the configuration steps 
required are outlined in the subsequent two sections. 


Note: Using non-DLR switches can result in loss of unicast frames for some period of time 
following a ring fault or restoration. After a ring fault/restoration, the switch’s MAC learning 
tables may be invalid as devices are now reachable through different ports. Until the MAC 
learning tables are updated as a result of devices sending frames, unicast frames may not reach 
the target devices. 


For an EtherNet/IP I/O connection, typically one cyclic production cycle will be lost. In some 
circumstances, more than a single production may be lost. For example, in the case where the 
T-O RPI is slower than the O-T RPI, O-T packets will not be delivered until the target device 
sends a packet to update the switch’s MAC table. Or, if the device is a polled device (such as 
an explicit message server), or has only unidirectional connections, the device may not generate 
packets to update the switch’s MAC learning table. 


In such cases where undesirable unicast packet loss occurs, the user has several options: 

1. Configure static unicast MAC addresses for the switch ports connected to the ring 

2. Disable unicast MAC learning in the switch 

3. Use a DLR-capable device such as a 3-port switch to connect the larger switch to the ring 


As described in section 9-5.2, DLR protocol rings can be used in topologies with switches that 
are running IEEE Spanning Tree Protocols (STP, RSTP, MSTP). In the most common 
configurations, as shown in section 9-5.1, DLR rings can be connected to such managed 
switches without issue. 


The DLR protocol does not support any non-DLR loop(s) passing through portions of a DLR 
ring, irrespective of whether a switch supports DLR or not and irrespective of whether it 
supports Spanning Tree Protocols. Figure 9-5.7 and Figure 9-5.8 show examples of 
unsupported DLR topologies, with non-DLR loops traversing the DLR ring. Such topologies 
can cause erratic network behavior and can be resolved manually by removing one or more of 
non-DLR redundant links. 


— 9-24 — 
Edition 1.18 
SINGLE SUBSCRIPTION ONLY; SUBSCRIPTION TERMS AND CONDITIONS OUTLINED ON PAGE (iii) 


Volume 2: EtherNet/IP Adaptation of CIP, Chapter 9: Indicators & Middle Layers 


9-5.7.3.1 


Figure 9-5.7 Unsupported Topology, Example 1 
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Figure 9-5.8 Unsupported Topology, Example 2 
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Switch Configuration For Non-VLAN Rings 


This section outlines the general procedure to configure a managed switch for a non- VLAN 
based ring network. Actual commands to configure a specific switch is switch dependant, but 
can be deduced from the procedure below. 


1. Configure quality of service (QoS) to ensure deterministic behavior and high performance 
for ring operation. The switch should support at least two queues, preferably four, and must 
support strict priority scheduling for the highest priority queue. The highest priority queue 
on ports connected to ring network must be configured for ring protocol frames (802.1Q 
priority 7). Note that while it is acceptable to share highest priority queue with IEEE 1588 
PTP event messages, it is strongly recommended that no other traffic be shared on this 
queue. For IP frames the switch should use the DSCP value. For non-IP frames the priority 
in the 802.1Q header should be used. 


2. If required, configure the two ports of switch connected ring network to preserve IEEE 
802.1Q tag priority of ring protocol frames when they pass through the ports. Most switches 
will need no specific configuration for this step. 
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3. Disable IP multicast filtering on the two ports of switch connected to ring. This step must be 
done to facilitate uninterrupted delivery of EtherNet/IP multicast connection data after a ring 
reconfiguration. Some switches provide a direct way to configure forwarding of all IP 
multicast traffic on a per port basis. Other switches provide a way to configure designation 
of individual ports as multicast router ports. Both methods achieve the same effect of 
disabling multicast filtering on specific ports. See RFC4541 -- Considerations for Internet 
Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping 
Switches for details. 


4. Statically configure the three multicast addresses used by ring protocol to be forwarded only 
on two ports of switch connected to ring. This step must be done to prevent multicast ring 
protocol frames from being forwarded on other ports of switch. 


5. Configure unicast MAC addresses of all configured ring supervisors statically into the MAC 
table of switch such that unicast traffic destined for ring supervisors will be forwarded 
through both ports of switch connected to ring. This step must be done to prevent switch 
from getting confused by bi-directional ring beacons from active ring supervisor. 


Switch Configuration for a VLAN-based Ring 


This section outlines the general procedure to configure a managed switch for a VLAN-based 
ring network. The actual configuration commands are switch-dependant, but can be deduced 
from the procedure below. Assume all ring supervisors have been configured to use VLAN ID 
ring_vlan_id for ring protocol frames. Note that the ring_vian_id will be used only for ring 
protocol frames. Assume that the switch will use VLAN ID default_vlan_id for all untagged 
frame traffic including EtherNet/IP frames. 


1. Configure quality of service (QoS) to ensure deterministic behavior and high performance 
for ring operation. The switch should support at least two queues, preferably four, and must 
support strict priority scheduling for the highest priority queue. The highest priority queue 
on ports connected to ring network must be configured for ring protocol frames (802.1Q 
priority 7). Note that while it is acceptable to share highest priority queue with IEEE 1588 
PTP event messages, it is strongly recommended that no other traffic be shared on this 
queue. For IP frames the switch should use the DSCP value. For non-IP frames the priority 
in the 802.1Q header should be used. 


2. Create VLAN’s for ring_vian_id and default_vlan_id on switch. 


3. Configure the two ports of switch connected ring to participate in VLAN’s ring_vlan_id and 
default_vlan_id. The two ports should be configured such that traffic on default_vlan_id 
should go untagged on egress and incoming untagged traffic should be assigned to 
default_vlan_id. The two ports should be configured to preserve VLAN tag on ring_vlan_id 
when ring protocol frames pass through the ports. Care must be taken to ensure that none of 
the other ports on switch participate in VLAN ring_vlan_id. 


4. Disable IP multicast filtering on the two ports of switch connected to ring, but only for 
VLAN default_vian_id. This step must be done to facilitate bump less delivery of 
EtherNet/IP multicast connection data after a ring reconfiguration. Some switches provide a 
direct way to configure forwarding of all IP multicast traffic on a per port basis. Other 
switches provide a way to configure designation of individual ports as multicast router ports. 
Both methods achieve the same effect of disabling multicast filtering on specific ports. See 
RFC4541 -- Considerations for Internet Group Management Protocol (IGMP) and Multicast 
Listener Discovery (MLD) Snooping Switches for details. 
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5. Configure unicast MAC addresses of all configured ring supervisors statically into the MAC 
table of switch such that unicast traffic destined for ring supervisors will be forwarded 
through both ports of switch connected to ring. This configuration must be done for both 
VLAN’s ring_vlan_id and default_vlan_id. This step must be done to prevent switch from 
getting confused by bi-directional ring beacons from active ring supervisor. This step may 
be omitted, but will result in minor loss of performance. 


Redundant Gateway Devices on DLR Network 


Redundant gateway devices on a DLR network allow multiple connections to the network 
infrastructure outside of the DLR network. If one of the gateway devices fails or the connection 
from a gateway device to the outside network infrastructure fails there will be an alternate path 
for communications. This section specifies the behavior of redundant gateway devices on a 
DLR network. 


Supported Topologies 


Figure 9-5.9 shows a DLR network connected to network infrastructure outside of DLR 
network through dual redundant gateway devices. In general, two or more redundant gateway 
devices on a DLR network are supported. One of the gateway devices will function as the 
active gateway device, while others function as backup gateway devices. At any given time, 
only the active gateway device will forward traffic between the DLR network and the network 
infrastructure outside of the DLR network. The backup gateway devices will block all traffic 
between the DLR network and the network infrastructure outside of the DLR network, in effect 
isolating the two networks. 
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Figure 9-5.9 DLR Ring Connected to Switches Through Redundant Gateways 
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When redundant gateway devices are used on a DLR network to provide multiple connections 
to network infrastructure outside of the DLR network, DLR aware non-redundant gateway 
devices and non-DLR aware switches shall not be used on the DLR network to connect to 
network infrastructure outside of the DLR network. 


— 9-28 — 
Edition 1.18 
SINGLE SUBSCRIPTION ONLY; SUBSCRIPTION TERMS AND CONDITIONS OUTLINED ON PAGE (iii) 


Volume 2: EtherNet/IP Adaptation of CIP, Chapter 9: Indicators & Middle Layers 


9-5.8.2 


9-5.8.3 


Redundant Gateway Capable Device 
Figure 9-5.10 DLR Redundant Gateway Capable Device 
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Figure 9-5.10 shows the conceptual elements of a DLR redundant gateway capable device. It 
has two DLR ports to connect to the DLR network and one or more uplink ports to connect to 
network infrastructure outside of the DLR network. All the non-DLR ports on a gateway device 
may not be uplink ports. Whether a non-DLR port can behave as an uplink port is dependent on 
both implementation and end user configuration. 


The gateway device shall implement DLR protocol on its two DLR ports. It shall implement 
either IEEE 802.1D RSTP or IEEE 802.1Q MSTP on its uplink ports. It may optionally 
implement STP or other protocols on its uplink ports. It shall have the ability to block traffic 
from being forwarded between DLR ports and uplink ports when functioning as a backup 
gateway device. While blocking traffic in backup mode, it shall forward DLR traffic only 
between its two DLR ports and shall forward uplink port traffic only between its uplink ports. 
There are many ways to implement such blocking behavior. For example one way is to use 
additional VLAN tagging inside the gateway device. 


Irrespective of whether a gateway is blocking or forwarding traffic between DLR ports and 
uplink ports, it shall never forward DLR protocol frames with the exception of 
Learning_Update frames between DLR ports and uplink ports. Only the active gateway device 
shall forward Learning Update frames to uplink ports when traffic forwarding is enabled 
between DLR ports and uplink ports as specified in section 9-5.10.4. 


When a gateway switchover occurs, the new active gateway device shall send the topology 
change notification message on its uplink ports that is appropriate for the protocol currently 
enabled on its uplink ports. This requirement does not apply if no protocol is currently enabled 
on its uplink ports. 


Redundant Gateway Device Behavior 


A redundant gateway device shall implement two independent state machines. One state 
machine shall be for base DLR function i.e. a Beacon based ring node or an Announce based 
ring node or a DLR supervisor as appropriate for the device capability. A second state machine 
shall be implemented for the redundant gateway function. This section provides a general 
overview of redundant gateway device behavior. Refer to section 9-5.10.4 for details. 
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Table 9-5.2 summarizes variables used in the redundant gateway behavior and messages. The 
DLR Object (Chapter 5) exposes these variables (with the exception of the Gateway State and 
Active Listen Timeout) via object attributes. 


Table 9-5.2 Redundant Gateway Variables 


Gateway Variable 


Description 


Gateway State 


Internal state of a node’s gateway state machine: 


IDLE_STATE - initial state for gateways and when redundant gateway function has not been 
enabled. 


ACTIVE_LISTEN_STATE ~ when a gateway is actively transmitting Advertise frames and is also 
listening for Advertise frames to detect the presence of another active gateway with traffic 
forwarding blocked between its DLR ports and uplink ports. 


ACTIVE_NORMAL_ STATE — normal function in active gateway mode. 


BACKUP_NORMAL_ STATE - normal function in backup gateway mode. 


FAULT_STATE - while uplink connection fault persists. 


Redundant Gateway Enable 


A Boolean value to indicate if redundant gateway function is enabled on a redundant gateway 
capable device. The default value is FALSE. 


Gateway Precedence 


Precedence value assigned to a gateway, and transmitted in Advertise frames. Used to select active 
gateway when multiple gateways have been configured. 
Default value is 0. Can be changed via the DLR Object. 


Advertise Interval 


Interval at which the active gateway node sends Advertise frames. Gateways shall support a range 
from 1000 microseconds to 100 milliseconds. The default value shall be 2000 microseconds. 
Gateways may support an Advertise Interval smaller than 1000 microseconds, but this is not 
required. The absolute minimum Advertise Interval is 200 microseconds. 


Advertise Timeout 


Amount of time backup gateway nodes shall wait before timing out reception of Advertise frames 
and taking the appropriate action. Gateways shall support a range from 2500 microseconds to 500 
milliseconds. The default shall be 5000 microseconds. Gateways may support an Advertise 
Timeout smaller than 2500 microseconds, but this is not required. The absolute minimum 
Advertise Timeout is 500 microseconds. 


Learning Update Enable 


A Boolean value to indicate if all nodes in the DLR network should transmit Learning_Update 
frames when they receive a Flush_Tables frame from an active gateway. This parameter is encoded 
by the active gateway in its Flush_Tables frame. The Learning_Update frames from DLR devices 
accelerate the new network topology learning by all non-DLR switches outside the DLR network 
after an active gateway switchover. The default value is TRUE. 


Active Listen Timeout 


Amount of time a gateway device shall wait in ACTIVE_LISTEN_STATE listening for Advertise 
frames with higher precedence from another gateway device. The value is equal to current 
Advertise Timeout duration. 


9-5.8.3.2 Startup 


A gateway device shall start (on power up or when redundant gateway function is enabled) in 
IDLE_STATE with traffic forwarding blocked between DLR ports and uplink ports. If 
redundant gateway function is enabled, it shall transition to ACTIVE_LISTEN_STATE with 
traffic forwarding blocked between its DLR ports and uplink ports. If redundant gateway 
function is disabled, it shall enable traffic forwarding between its DLR ports and uplink ports. 
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Figure 9-5.11 Advertise Frame 
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Immediately upon transition to ACTIVE_LISTEN_STATE and once every Advertise Interval 
thereafter, the gateway shall transmit Advertise frames through its DLR ports. It shall also 
listen for Advertise frames transmitted by another active gateway device on its DLR ports. If an 
Advertise frame is received from another active gateway device with higher Precedence or in 
case of a tie, if the source MAC address of the other gateway is numerically greater than its 
own MAC address, it shall transition to BACKUP_NORMAL_ STATE with traffic forwarding 
blocked between its DLR ports and uplink ports, and shall stop transmission of Advertise 
frames. 


Normal Operation 


While in ACTIVE_LISTEN_STATE, if no Advertise frames are received or no Advertise 
frames with higher Precedence (or numerically higher source MAC address in case of a tie) are 
received for the duration of Active Listen Timeout, it shall transition to 
ACTIVE_NORMAL_STATE and shall become the active gateway device with traffic 
forwarding enabled between its DLR ports and uplink ports. Immediately upon transition to 
ACTIVE_NORMAL_STATE and once every Advertise Interval thereafter, the gateway shall 
transmit Advertise frames through its DLR ports. 


Immediately upon transition to ACTTIVE_NORMAL_STATE, an active gateway device shall 
transmit a Flush_Tables frame to all DLR nodes and shall flush its own unicast and multicast 
address learning filter tables. Upon receiving a Flush_tables frame, a DLR node shall flush its 
unicast and multicast MAC address learning tables. If the Learning Update Enable field in the 
Flush_Tables frame is set to TRUE, a DLR node shall also transmit a Learning_Update frame 
to accelerate new network topology learning by non-DLR switches outside of the DLR 
network. 


While in ACTIVE_NORMAL_STATE, if an Advertise frame is received from another active 
gateway device with higher Precedence (or numerically higher source MAC address in case of 
a tie), the receiver shall transition to BACKUP_NORMAL_STATE with traffic forwarding 
blocked between its DLR ports and uplink ports, and shall stop transmission of Advertise 
frames. 
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9-5.8.3.4 


9-5.8.3.5 


9-5.8.3.6 


9-5.8.3.7 


Uplink Fault Detection 


While in ACTIVE_LISTEN_STATE or BACKUP_NORMAL_ STATE, if the physical 
connections are lost on all its uplink ports or a higher level connection fault is detected through 
an optional protocol implemented on the uplink ports, a gateway device shall transition to 
FAULT_STATE with traffic forwarding blocked between its DLR ports and uplink ports. It 
shall not transmit Advertise frames in FAULT_STATE. 


While in ACTIVE_NORMAL_STATE, if the physical connections are lost on all its uplink 
ports or a higher level connection fault is detected through an optional protocol implemented 
on the uplink ports, an active gateway device shall transmit an Advertise frame with 
FAULT_STATE encoded in the frame and shall transition to FAULT_STATE with traffic 
forwarding blocked between its DLR ports and uplink ports. It shall not transmit Advertise 
frames in FAULT_STATE thereafter. 


Gateway Switchover 


While in BACKUP_NORMAL_STATE, if an Advertise frame is received from an active 
gateway with FAULT_STATE encoded or if no Advertise frames are received from any active 
gateway for the duration of the Advertise Timeout, a backup gateway device shall transition to 
ACTIVE_LISTEN_STATE with traffic forwarding blocked between its DLR ports and uplink 
ports. It shall then behave as described in section 9-5.8.3.2 for ACTIVE_LISTEN_STATE. 


Uplink Restoration 


When a faulted uplink connection is restored and the Precedence of the active gateway is 
higher than Precedence of itself (or has a numerically higher MAC address than its own MAC 
address in case of a tie), a gateway device shall transition from FAULT_STATE to 
BACKUP_NORMAL_STATE and shall block traffic forwarding between its DLR ports and 
uplink ports. 


When a faulted uplink connection is restored and the Precedence of active gateway is lower 
than Precedence of itself (or has a numerically lower MAC address than its own MAC address 
in case of a tie) or there is no active gateway transmitting Advertise frames, a gateway device 
shall transition from FAULT_STATE to ACTIVE_LISTEN_STATE and shall block traffic 
forwarding between its DLR ports and uplink ports. It shall then behave as described in section 
9-5.8.3.2 for ACTIVE_LISTEN_STATE. 


Partial Network Fault 


It is possible for a partial network fault to occur such that traffic is lost in only one direction. In 
such a situation, it is possible for a backup gateway device to misdiagnose that the active 
gateway device is lost. To prevent multiple gateway devices from enabling traffic forwarding 
between their DLR ports and uplink ports, an active gateway device shall transition to 
FAULT_STATE and shall block traffic forwarding between its DLR ports and uplink ports if it 
receives an Advertise frame with ACTIVE _NORMAL_STATE as the gateway state from 
another active gateway device with lower Precedence (or numerically lower MAC address in 
case of a tie). It shall indicate the condition through the Redundant Gateway Status attribute in 
the DLR object. It shall set the Active Gateway Address and Active Gateway Precedence 
attributes to that of the other active gateway with lower precedence. The user must explicitly 
clear this condition via the DLR object using the Clear_Gateway_Partial_Fault service. 
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9-5.9 
9-5.9.1 


9-5.9.2 


DLR Messages 
General 


The following sections specify the DLR protocol messages. Several items of importance should 
be noted: 


1. DLR messages with the exception of Learning_Update, are sent using the IEEE 802.1Q 
frame format. Messages shall be transmitted using the highest priority (7), which shall be 
preserved as the DLR frames are transferred through the LAN. 


2. To distinguish the DLR frame data types from CIP data types, the UINTx convention is 
used to indicate an x-bit, unsigned integer value in the tables below. Multi-byte data types 
within the DLR frames shall be encoded using big-endian byte ordering. 


3. The following destination MAC addresses are used for DLR messages: 
Table 9-5.3 DLR MAC Address Usage 


MAC Address Usage 
01-21-6C-00-00-01 Beacon 
01-21-6C-00-00-02 Neighbor_Check_Request, Neighbor_Check_Response, Sign_On 
01-21-6C-00-00-03 Announce, Locate_Fault, Flush_Tables 
01-21-6C-00-00-04 Advertise 
01-21-6C-00-00-05 Learning_Update 
MAC address of active ring Link_Status / Neighbor_Status 
supervisor 


Common Frame Header 


DLR messages with the exception of Learning_Update, shall be sent using the IEEE 802.1Q 
frame format, as shown below: 


Table 9-5.4 Common Frame Header Format 


Byte Field Type Remarks 
0 Destination MAC Address UINTS8[6] 
6 Source MAC Address UINTS8[6] 
12 802.1Q Tag Type UINT16 = 0x8100 
14 802.1Q Tag control UINT16 = 0xE000 + VLAN_ID (default value=0) 
16 Ring EtherType UINT16 = Ox80E1 
18 Ring Sub-type UINTS8 = 0x02 
19 Ring Protocol Version UINT8 = 0x01 


The following common fields are used in the DLR message payload: 
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9-5.9.3 


Table 9-5.5 DLR Message Payload Fields 


Byte Field Type Remarks 

20 Frame Type | UINT8 Identifies the DLR message type. See Table 9-5.6 DLR Frame 
Types 

21 Source Port | UINT8 Identifies the port on the device through which this message 
originated: 
0x00 — Port 1 or Port 2 
OxO1 — Port I 
0x02 — Port 2 

22 Source IP UINT32 Source IP address of the sending node. If none is configured, the 

Address value shall be 0. 

26 Sequence Id | UINT32 DLR message sequence Id. When originating a message a node 
shall increment the Sequence Id by 1. When responding to a 
message (Neighbor_Check response and Sign_On), a node shall 
use the Sequence Id from the original request message. 

30. Dependent on DLR See Tables below 


message type 


FCS 


UINT32 


IEEE 802.3 FCS 


Table 9-5.6 DLR Frame Types 


Value Name Frame Format 
0x01 Beacon 
0x02 Neighbor_Check_Request 
0x03 Neighbor_Check_Response 
Ox04 Link_Status / Neighbor_Status Common Frame Format, see Table 9-5.4 Common. 
0x05 Locate_Fault Frame Header Format and Table 9-5.5 DLR Message 
0x06 Announce Payload Fields 
0x07 Sign_On 
0x08 Advertise 
0x09 Flush_Tables 
Ox0A. Learning_Update See section 9-5.9.12 


Beacon Frame 


The Beacon frame is sent by the active ring supervisor to determine the health of the ring 


topology. 


Table 9-5.7 shows the format of the Beacon frame: 
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9-5.9.4 


9-5.9.5 


Table 9-5.7 Beacon Frame Format 


Byte Field Type Remarks 
20 Frame Type UINTS8 = 0x01 
21 Source Port UINT8 = 0x0 
22 Source IP Address UINT32 = 0x0, if source has no IP address 
26 Sequence Id UINT32 
30 Ring State UINT8 See Table 9-5.8 below 
31 Supervisor Precedence UINTS8 From the DLR Object 
32 Beacon Interval UINT32 From the DLR Object 
36 Beacon Timeout UINT32 In Microseconds 
40 Reserved UINTS8[20] Sender shall set to zero, receiver shall ignore 
60 FCS UINT32 
Table 9-5.8 Ring State Values 
Ring State Value 
RING_NORMAL_STATE Ox01 
RING_FAULT_STATE 0x02 


Neighbor_Check_Request 


The Neighbor_Check_Request is sent by a ring node as a result of receiving a Locate_Fault 


frame, and by an active ring supervisor when Beacon loss has been detected. 


Table 9-5.9 Neighbor_Check_Request Frame Format 


Byte Field Type Remarks 

20 Frame Type UINTS8 = 0x02 

21 Source Port UINTS = 0x1 or 0x2 

22 Source IP Address UINT32 = 0x0, if source has no IP address 

26 Sequence Id UINT32 

30 Reserved UINTS8[30] Sender shall set to zero, receiver shall ignore 
60 FCS UINT32 


Neighbor_Check_Response 


The Neighbor_Check_Response frame is sent in response to the Neighbor_Check_Request. 


Table 9-5.10 Neighbor_Check_Response Frame Format 


Byte Field Type Remarks 
20 Frame Type UINTS8 = 0x03 
21 Source Port UINT8 = 0x1 or 0x2 
22 Source IP Address UINT32 = 0x0, if source has no IP address 
26 Sequence Id UINT32 = Sequence Id of Neighbor_Check_Request 
30 Request Source Port UINT8 = Source Port of Neighbor_Check_Request 
31 Reserved UINTS8[29] Sender shall set to zero, receiver shall ignore 
60 FCS UINT32 
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9-5.9.6 Link_Status/Neighbor_Status 
A Link_Status frame is sent when a ring node has detected a link failure or in response to a 
Locate_Fault frame when one of its ports is not active. A Neighbor_Status frame is sent when 
the Neighbor Check process has timed out. These frames share the same format, differentiated 
by the Link/Neighbor Status Flag. 
Table 9-5.11 Link_Status/Neighbor_Status Frame Format 
Byte Field Type Remarks 
20 Frame Type UINTS8 = 0x04 
21 Source Port UINTS8 =0 
a2. Source IP Address UINT32 = 0x0, if source has no IP address 
26 Sequence Id UINT32 
30 Link/Neighbor Status UINT8 Interpreted as a bit map, see 
Table 9-5.12 below 
31 Reserved UINT8[29] Sender shall set to zero, receiver shall ignore 
60 FCS UINT32 
Table 9-5.12 Link/Neighbor Status Values 
Bit(s): Called Definition 
0) 
Pater Port 1 Active Set to 1 if node’s port | is active 
(least significant) 
1 Port 2 Active Set to 1 if node’s port 2 is active 
2-6 Reserved Sender shall set to zero, receiver shall ignore 
Fi 3 Set to 0 if frame is Link_Status frame 
: Linki Netehibor Status, Eee. Set to | if frame is Neighbor_Status frame 
9-5.9.7 Locate_Fault 


The Locate_Fault frame is sent by the active ring supervisor as a result of loss of Beacon 


frames, and as a result of the Verify_Fault_Location service sent to the DLR Object. 
Table 9-5.13 Locate_Fault Frame Format 
Byte Field Type Remarks 
20 Frame Type UINTS = 0x05 
21 Source Port UINT8 = 0x0 
22 Source IP Address UINT32 = 0x0, if source has no IP address 
26 Sequence Id UINT32 
30 Reserved UINT8[30] Sender shall set to zero, receiver shall ignore 
60 FCS UINT32 
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9-5.9.8 


9-5.9.9 


Announce 


The Announce frame is sent by the active ring supervisor to indicate a change in the ring state, 


and to noti 


Table 9-5.14 Announce Frame Format 


fy the ring topology to announce-based nodes. 


Byte Field Type Remarks 
20 Frame Type UINT8 = 0x06 
21 Source Port UINT8 = 0x0 
22 Source IP Address UINT32 = 0x0, if source has no IP address 
26 Sequence Id UINT32 
30 Ring State UINT8 As in the Beacon frame 
31 Reserved UINT8[29] Sender shall set to zero, receiver shall ignore 
60 FCS UINT32 
Sign_On 


The Sign_On frame is sent initially by the active ring supervisor, in order to identify all 


participating ring nodes. The receiving ring partici 


pant node traps the Sign_On frame and 


forwards it only to the host CPU. The host CPU increments the number of nodes in list, add its 
own addresses to list and transmits the Sign_On frame only through the other port than the 
receiving port. 


Table 9-5.15 Sign_On Frame Format 


Byte Field Type Remarks 
20 Frame Type UINT8 = 0x07 
21 Source Port UINTS = 0x1 or 0x2 
22 Source IP Address UINT32 = 0x0, if source has no IP address 
26 Sequence Id UINT32 
30 Number of Nodes in UINTI6 
List 
32 Node 1 MAC Address UINTS8[6] Node 1 is always the active supervisor 
38 Node | IP Address UINT32 = 0x0, if no IP address 
42 Node 2 MAC Address UINTS8[6] 
48 Node 2 IP Address UINT32 = 0x0, if no IP address 
Reserved UINTS8[...] Sender shall set to zero, receiver shall ignore 
N FCS UINT32 N should be padded to at least 60, if needed 
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9-5.9.10 Advertise Frame 

The Advertise frame is sent by the active gateway to indicate presence of active gateway and to 

notify gateway faults. 

Table 9-5.16 Advertise Frame Format 

Byte Field Type Remarks 
20 Frame Type UINT8 =0x08 
21 Source Port UINTS =0x0 
22. Source IPAddress UINT32 =0x0, if source has no IP 
address 

26 Sequence ID UINT32 
30. Gateway State UINT8 See Table 9-5.17 below 
31 Gateway Precedence UINTS8 From the DLR Object 
32 Advertise Interval UINT32 From the DLR Object 
36 Advertise Timeout UINT32 From the DLR Object 
40 Learning Update Enable UINT8 From the DLR Object 
41 Reserved UINTS8[19. 
60 FCS UINT32 

Table 9-5.17 Gateway State Values 

Gateway State Value 
ACTIVE_LISTEN_STATE Ox01 
ACTIVE_NORMAL_STATE 0x02 
FAULT_STATE 0x03 
9-5.9.11 Flush_Tables Frame 


The Flush_Tables frame is sent by the new active gateway to indicate that DLR nodes should 
flush their unicast and multicast MAC address learning tables. 


Table 9-5.18 Flush_Tables Frame Format 


Byte Field Type Remarks 
20 Frame Type UINTS = 0x09 
21 Source Port UINTS = 0x0 
22 Source IP Address UINT32 = 0x0, if source has no IP address 
26 Sequence Id UINT32 
30 Learning Update Enable UINT8 From the DLR Object 
31 Reserved UINTS8[29] 
60 FCS UINT32 
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9-5.9.12 


Learning_Update Frame 


The Learning _Update frame is sent by all DLR nodes upon receiving a Flush_Tables frame 
from active gateway and if Learning Update Enable field is set to TRUE to accelerate learning 
of new network topology by non-DLR switches outside of DLR network. The 
Learning_Update frame is an untagged 802.3 frame as shown 
DLR switches outside of DLR network will not drop it. 


Table 9-5.19 Learning_Update Frame Format 


below, so that VLAN aware non- 


Byte Field Type Remarks 
0 Destination MAC Address UINT8[6] 
6 Source MAC Address UINT8[6] 
12 Ring EtherType UINT16 = Ox80E1 
14 Ring Sub-type UINT8 = 0x02 
15 Ring Protocol Version UINTS8 = 0x01 
16 Frame Type UINTS = 0x0A 
17 Source Port UINT8 = 0x0 
18 Source IP Address UINT32 = 0x0, if source has no IP address 
22 Sequence ID UINT32 
26 Reserved UINTS8[34] 
60 FCS UINT32 
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9-5.10 


9-5.10.1_ Beacon-Based Ring Node 


State Diagrams and Event Matrixes 


Figure 9-5.12 State Transition Diagram for Beacon Frame Based Non-Supervisor Ring Node 


Power Up 
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Table 9-5.20 Parameter Values for Beacon frame based Non-Supervisor Ring Node 


Parameter 


Value 


Active supervisor precedence 


Obtained from Beacon frame 


Active supervisor MAC address 


Obtained from Beacon frame 


Ring protocol VLAN ID 


Obtained from Beacon frame 


Beacon timeout duration 


Obtained from Beacon frame 


Neighbor check timeout duration 


100 milliseconds 


Maximum retry limit for 
Neighbor_Check_Request frame 


3 (total number of tries) 
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The following notes apply to the State-Event-Action table: 


e LastBenRevPort is a bit string variable used to track port(s) on which last Beacon frame was 


received, with the following bit definitions: 


Description 


0 Set if a beacon frame from the active supervisor has been received on Port 1 


1 Set if a beacon frame from the active supervisor has been received on Port 2 


Not used; set to 0 


e MAC address 11-22-33-44-55-66 shall be encoded as 0x112233445566 for numerical 
comparison in case of supervisor precedence tie. 


¢ Nodes shall statically configure unicast MAC address of current active ring supervisor into 
unicast MAC learning table to be forwarded only through both ring ports. 
Table 9-5.21 State-Event-Action Table for Beacon Frame Based Non-Supervisor Ring Node 
ea Current State Event Action(s) 
1 None Power up Initialize and transition to IDLE_STATE 
2 IDLE_STATE Beacon frame from a ring Save as active supervisor precedence, MAC 
supervisor received on port |__| address, VLAN ID and beacon timeout 
duration 
Set LastBenRevPort to 1 
Start beacon timeout timer for port 1 
Transition to FAULT_STATE and flush 
unicast MAC address learning table 
3 IDLE_STATE Beacon frame from a ring Save as active supervisor precedence, MAC 
supervisor received on port 2 address, VLAN ID and beacon timeout 
Set LastBcnRevPort to 2 
Start beacon timeout timer for port 2 
Transition to FAULT_STATE and flush 
unicast MAC address learning table 
4 IDLE_STATE Link lost on port 1 Stop forwarding frames on port 1 
is} IDLE_STATE Link lost on port 2 Stop forwarding frames on port 2 
6 IDLE_STATE Link restored on port 1 Start forwarding frames on port 1 
of IDLE_STATE Link restored on port 2 Start forwarding frames on port 2 
8 IDLE_STATE Frame from self received on Do not forward frame on network and drop it 
port 1 or port 2 (If capable of doing so) 
9 IDLE_STATE Locate_Fault or Ignore 
Neighbor_Check_Request or 
Neighbor_Check_Response or 
Sign_On frame received on 
port | or port 2 
10 FAULT_STATE Beacon frame from active ring | Restart port | beacon timeout timer 
supervisor received on port 1 
and LastBenRevPort is 1 
11 FAULT_STATE Beacon frame from active ring | Restart port 2 beacon timeout timer 
supervisor received on port 2 
and LastBenRevPort is 2 
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Event 


No. Current State Event Action(s) 
12 FAULT_STATE Beacon timeout timer expired | Stop neighbor check timeout timers for both 
for port | and ports, transition to IDLE_STATE and flush 
LastBenRevPort is 1 unicast MAC address learning table 
13 FAULT_STATE Beacon timeout timer expired | Stop neighbor check timeout timers for both 
for port 2 and ports, transition to IDLE_STATE and flush 
LastBenRevPort is 2 unicast MAC address learning table 
14 FAULT_STATE Beacon frame from active ring | Set LastBcnRevPort to 3 
supervisor received on port 2 | Start/restart port 2 beacon timeout timer 
and VastBenRevPortis 1'or.5 If the ring state of beacon frame is not 
RING_NORMAL_STATE, return 
Else, stop neighbor check timeout timers for 
both ports 
Transition to NORMAL_STATE and flush 
unicast MAC address learning table 
15 FAULT_STATE Beacon frame from active ring | Set LastBenRevPort to 3 
Supervisor received on port 1 | Start/restart port 1 beacon timeout timer 
and LastBenRevPort is 2 or 3 If the ring state of beacon frame is not 
RING_NORMAL_STATE, return 
Else, stop neighbor check timeout timers for 
both ports 
Transition to NORMAL_STATE and flush 
unicast MAC address learning table 
16 FAULT_STATE Beacon frame from different a. If new supervisor has lower precedence 


ring supervisor MAC address 
than active ring supervisor is 
received on port I 


(or numerically lower MAC address in 

case of tie) than active supervisor: 

i. If embedded switch hardware 
determines precedence, drop the 
new Beacon frame and return 

ii. If embedded switch hardware does 
not determine precedence, the new 
Beacon frame shall be forwarded 
on the other ring port and to the 
host; the host CPU shall ignore the 
new Beacon frame and return 

b. _ Else, stop beacon timeout timers for 
both ports 

c. Save new active supervisor precedence, 
MAC address, VLAN ID and beacon 
timeout duration 

d. Set LastBcenRevPort to 1 

e. Start beacon timeout timer for port 1 


f. | Stay in FAULT_STATE and flush 
unicast MAC address learning table 
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wae Current State Event Action(s) 

17 FAULT_STATE Beacon frame from different | a. If new supervisor has lower precedence 
ring supervisor MAC address (or numerically lower MAC address in 
than active ring supervisor is case of tie) than active supervisor: 
received on port 2 i. If embedded switch hardware 

determines precedence, drop the 
new Beacon frame and return 
ii, If embedded switch hardware does 
not determine precedence, the new 
Beacon frame shall be forwarded 
on the other ring port and to the 
host; the host CPU shall ignore the 
new Beacon frame and return 
b. Else, stop beacon timeout timers for 
both ports 
c. Save new active supervisor precedence, 
MAC address, VLAN ID and beacon 
timeout duration 
d. Set LastBcnRevPort to 2 
e. Start beacon timeout timer for port 2 
f. Stay in FAULT_STATE and flush 
unicast MAC address learning table 

18 FAULT_STATE Link lost on port 1 and Stop port | beacon timeout timer and 
LastBenRevPort is 1 neighbor check timeout timers for both ports 

Transition to IDLE_STATE and flush 
unicast MAC address learning table 

19 FAULT_STATE Link lost on port | and Send Link_Status frame to active ring 
LastBcnRevPort is 2 supervisor 

20 FAULT_STATE Link lost on port 2 and Stop port 2 beacon timeout timer and 
LastBenRevPort is 2 neighbor check timeout timers for both ports 

Transition to IDLE_STATE and flush 
unicast MAC address learning table 

21 FAULT_STATE Link lost on port 2 and Send Link_Status frame to active ring 
LastBcnRevPort is 1 supervisor 

22 FAULT_STATE Link restored on port 1 Start forwarding frames on port 1 

23 FAULT_STATE Link restored on port 2 Start forwarding frames on port 2 

24 FAULT_STATE Locate_Fault frame received _ | If link is not active on port 1 or port 2 send 
from active ring supervisor on | Link_Status frame to active ring supervisor 
port | or port 2 Else clear neighbor status for port | and 2, 

send Neighbor_Check_Request for port 1 
and 2, and start neighbor check timeout timer 
for port | and 2. 

25 FAULT_STATE Neighbor_Check_Request Send Neighbor_Check_Response frame on 
frame received on port 1 port 1 

26 FAULT_STATE Neighbor_Check_Request Send Neighbor_Check_Response frame on 
frame received on port 2 port 2 

27 FAULT_STATE Neighbor_Check_Response Stop neighbor check timeout timer for port 1 
frame received on port 1 and save neighbor status for port 1 

28 FAULT_STATE Neighbor_Check_Response Stop neighbor check timeout timer for port 2 


frame received on port 2 


and save neighbor status for port 2 
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ae Current State Event Action(s) 
29 FAULT_STATE Neighbor check timer timeout | If number of retries have not exceeded 
on port 1 maximum limit, send 
Neighbor_Check_Request on port | and start 
neighbor check timeout timer for port 1 
Else, send Neighbor_Status frame to active 
ring supervisor 
30 FAULT_STATE Neighbor check timer timeout | If number of retries have not exceeded 
on port 2 maximum limit, send 
Neighbor_Check_Request on port 2 and start 
neighbor check timeout timer for port 2 
Else, send Neighbor_Status frame to active 
ring supervisor 
31 FAULT_STATE Sign_On frame received on Ignore 
port | or port 2 
32 NORMAL_STATE | Link lost on port 1 Send Link_Status frame to active ring 
supervisor 
Stop beacon timeout timer for port 1 
Set LastBenRevPort to 2, transition to 
FAULT_STATE and flush unicast MAC 
address learning table 
33. NORMAL_STATE | Link lost on port 2 Send Link_Status frame to active ring 
supervisor 
Stop beacon timeout timer for port 2 
Set LastBcnRevPort to 1, transition to 
FAULT_STATE and flush unicast MAC 
address learning table 
34 NORMAL_STATE | Beacon frame from active ring | If the ring state of previous beacon frame 
supervisor with received on port 1 was not 
RING_FAULT_STATE RING_NORMAL_STATE, return 
received on port | Else, stop beacon timeout timer for port 2 
Set LastBcnRevPort to 1, transition to 
FAULT_STATE and flush unicast MAC 
address learning table 
35 NORMAL_STATE | Beacon frame from active ring | If the ring state of previous beacon frame 
supervisor with received on port 2 was not 
RING_FAULT_STATE RING_NORMAL_ STATE, return 
received on port 2 Else, stop beacon timeout timer for port | 
Set LastBcnRevPort to 2, transition to 
FAULT_STATE and flush unicast MAC 
address learning table 
36 NORMAL_STATE | Beacon timeout timer expired | Set LastBcnRcvPort to 2, transition to 
for port 1 FAULT_STATE and flush unicast MAC 
address learning table 
37. NORMAL_STATE | Beacon timeout timer expired | Set LastBcnRcvPort to 1, transition to 
for port 2 FAULT_STATE and flush unicast MAC. 
address learning table 
38 NORMAL_STATE | Beacon frame from active ring | Restart port | beacon timeout timer 
supervisor received on port 1 
39 NORMAL_STATE | Beacon frame from active ring | Restart port 2 beacon timeout timer 


supervisor received on port 2 
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em Current State Event Action(s) 

40 NORMAL_STATE | Beacon frame from different If new supervisor has lower precedence 
ring supervisor MAC address (or numerically lower MAC address in 
than active ring supervisor is case of tie) than active supervisor: 
received on port 1 i. If embedded switch hardware 

determines precedence, drop the 
new Beacon frame and return 

ii. If embedded switch hardware does 
not determine precedence, the new 
Beacon frame shall be forwarded 
on the other ring port and to the 
host; the host CPU shall ignore the 
new Beacon frame and return 

Else, stop beacon timeout timers for 

both ports. 

Save new active supervisor precedence, 

MAC address, VLAN ID and beacon 

timeout duration 

Set LastBcnRevPort to | 

Start beacon timeout timer for port 1 

Transition to FAULT_STATE and flush 

unicast MAC address learning table 

41 NORMAL_STATE | Beacon frame from different If new supervisor has lower precedence 
ring supervisor MAC address (or numerically lower MAC address in 
than active ring supervisor is case of tie) than active supervisor: 
Teceived on port 2 i. If embedded switch hardware 

determines precedence, drop the 
new Beacon frame and return 

ii. If embedded switch hardware does 
not determine precedence, the new 
Beacon frame shall be forwarded 
on the other ring port and to the 
host; the host CPU shall ignore the 
new Beacon frame and return 

Else, stop beacon timeout timers for 

both ports 

Save new active supervisor precedence, 

MAC address, VLAN ID and beacon 

timeout duration 

Set LastBcnRevPort to 2 

Start beacon timeout timer for port 2 

Transition to FAULT_STATE and flush 

unicast MAC address learning table 

42 NORMAL_STATE | Locate_Fault frame received Ignore 
from active ring supervisor on 
port | or port 2 

43 NORMAL_STATE | Neighbor_Check_Request or Tgnore 
Neighbor_Check_Response 
frame received on port | or 
port 2 

44 NORMAL_STATE | Sign_On frame received on Add node data to participant list and send 
port 1 frame through port 2 

45 NORMAL_STATE | Sign_On frame received on Add node data to participant list and send 
port 2 frame through port | 

46 IDLE_STATE Flush_Tables frame received Ignore 
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Event 


No. Current State Event Action(s) 


47 NORMAL_STATE | Flush_Tables frame received | Flush unicast and multicast MAC address. 
learning tables 


If Learning Update Enable field in 
Flush_Tables frame is set to TRUE, send 
Learning_Update frame 


48 FAULT_STATEO Flush_Tables frame received Flush unicast and multicast MAC address 
learning tables 

If Learning Update Enable field in 
Flush_Tables frame is set to TRUE, send 
Learning_Update frame 


Notes: 
Network Topology attribute shall be updated at events 1, 2,3, 12, 13, 18 and 20 to appropriate value. 


Network Status attribute shall be updated at events 1, 2, 3, 8, 12, 13, 14, 15, 18, 20, 32, 33, 34, 35, 
36, 37, 40 and 41 to appropriate value. 


9-5.10.2 Announce-Based Ring Node 


Figure 9-5.13 State Transition Diagram for Announce Frame Based Non-Supervisor Ring Node 
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Table 9-5.22 Parameter Values for Announce frame based Non-Supervisor Ring Node 


Parameter Value 


Active supervisor MAC address Obtained from Announce frame 
Ring protocol VLAN ID 


Announce timeout duration 


Obtained from Announce frame 


2.5 seconds 


Neighbor check timeout duration 100 milliseconds 


Maximum retry limit for 3 (total number of tries) 


Neighbor_Check_Request frame 


The following notes apply to the State-Event-Action table: 


e Sequence count must be verified for all Announce frames from the active ring supervisor 
using modular unsigned 32-bit integer arithmetic as described in Chapter 3-4.2, CIP 
Transport Class 0 and Class 1 Packet Ordering to deal with sequence number rollover. Only 
Announce frames with sequence count greater than last Announce frame should be 
processed. Others must be silently discarded. 

e Nodes shall statically configure unicast MAC address of current active ring supervisor into 
unicast MAC learning table to be forwarded only through both ring ports. 


e Nodes shall statically configure multicast MAC address of beacon frames into MAC 
learning table to be forwarded only through both ring ports and not to CPU. 
Table 9-5.23 State-Event-Action Table for Announce Frame Based Non-Supervisor Ring Node 
Event No. Current State Event Action(s) 
1 None Power up a. Initialize and transition to IDLE_STATE 
2 IDLE_STATE Announce frame from a ring a. Save as active supervisor MAC address, 
supervisor received on port | or VLAN ID and sequence count 
port 2 b. Start announce timeout timer 
c. Transition to ring state in Announce frame 
and flush unicast MAC address learning 
table 
3 IDLE_STATE Link lost on port 1 a. Stop forwarding frames on port 1 
4 IDLE_STATE Link lost on port 2 a. Stop forwarding frames on port 2 
5 IDLE_STATE Link restored on port 1 a. Start forwarding frames on port | 
6 IDLE_STATE Link restored on port 2 a. Start forwarding frames on port 2 
7 IDLE_STATE Frame from self received on port 1 | a. Do not forward frame on network and drop 
or port 2 it (If capable of doing so) 
8 IDLE_STATE Locate_Fault or a. Ignore 
Neighbor_Check_Request or 
Neighbor_Check_Response or 
Sign_On frame received on port 1 
or port 2 
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Event No. 


Current State 


Event 


Action(s) 


9 


FAULT_STATE 


Announce frame from active ring 
supervisor received on port | or 
port 2 with higher sequence count 
than last Announce frame 


ee oP 


Save sequence count 

Update VLAN ID (if different) 

Restart announce timeout timer 

Tf ring state in Announce frame is 
RING_NORMAL_STATE and links on 
both ports are active, stop neighbor check 
timeout timers for both ports, transition to 
NORMAL_STATE and flush unicast 
MAC address learning table 

Else, stay in FAULT_STATE 


FAULT_STATE 


Announce timeout timer expired 


Stop neighbor check timeout timers for 
both ports, transition to IDLE_STATE and 
flush unicast MAC address learning table 


FAULT_STATE 


Announce frame from different 
ring supervisor MAC address than 
active ring supervisor is received 
on port I or port 2 


Restart announce timeout timer and stop 
neighbor check timeout timers for both 
ports 

Save new active supervisor ,MAC address, 
VLAN ID and sequence count 

If ring state in Announce frame is 
RING_NORMAL_ STATE and links on 
both ports are active, transition to 
NORMAL_STATE and flush unicast 
MAC address learning table 


Else, stay in FAULT_STATE 


FAULT_STATE 


Link lost on port 1 


Tf link on port 2 is active, send Link_Status 
frame to active ring supervisor 

Else, stop announce timeout timer, stop 
neighbor check timeout timers for both 
ports, transition to IDLE_STATE and flush 
unicast MAC address learning table 


FAULT_STATE 


Link lost on port 2 


If link on port I is active, send Link_Status 
frame to active ring supervisor 

Else, stop announce timeout timer, stop 
neighbor check timeout timers for both 
ports, transition to IDLE_STATE and flush 
unicast MAC address learning table 


FAULT_STATE 


Link restored on port 1 


Start forwarding frames on port | 


15 


FAULT_STATE 


Link restored on port 2 


Start forwarding frames on port 2 


16 


FAULT_STATE 


Locate_Fault frame received from 
active ring supervisor 


If links are active on both ports, clear 
neighbor status for both ports, send 
Neighbor_Check_Request frame on both 
ports and start neighbor check timeout 
timer for both ports 

Else send Link_Status frame to active ring 
supervisor 


FAULT_STATE 


Neighbor_Check_Request frame 
received on port 1 


Send Neighbor_Check_Response frame on 
port 1 


FAULT_STATE 


Neighbor_Check_Request frame 
received on port 2 


Send Neighbor_Check_Response frame on 
port 2 


FAULT_STATE 


Neighbor_Check_Response frame 
received on port 1 


Stop neighbor check timeout timer for port 
1 and save neighbor status for port 1 


FAULT_STATE 


Neighbor_Check_Response frame 
received on port 2 


. Stop neighbor check timeout timer for port 


2 and save neighbor status for port 2 
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Event No. Current State Event Action(s) 
21 FAULT_STATE Neighbor check timer timeout on a. If number of retries have not exceeded 
port 1 maximum limit, send 
Neighbor_Check_Request on port 1 and 
start neighbor check timeout timer for port 
1 
b. Else, send Neighbor_Status frame to active 
ring supervisor 
22 FAULT_STATE Neighbor check timer timeout on a. If number of retries have not exceeded 
port 2 maximum limit, send 
Neighbor_Check_Request on port 2 and 
start neighbor check timeout timer for port 
2 
b. Else, send Neighbor_Status frame to active 
ring supervisor 
23 FAULT_STATE Sign_On frame received on port 1 a. Ignore 
or port 2 
24 NORMAL_STATE Link lost on port 1 a. Send Link_Status frame to active ring 
supervisor 
b. Transition to FAULT_STATE and flush 
unicast MAC address learning table 
25 NORMAL_STATE Link lost on port 2 a. Send Link_Status frame to active ring 
supervisor 
b. Transition to FAULT_STATE and flush 
unicast MAC address learning table 
26 NORMAL_STATE Announce frame from active ring a. Save sequence count 
Supervisor received on port | or b. Update VLAN ID (if different) 
port 2 with higher sequence count | © Restart announce timeout timer 
than last Announce frame : S . 
d. Ifring state in Announce frame is 
RING_FAULT_STATE, transition to 
FAULT_STATE and flush unicast MAC 
address learning table 
e. Else, stay in NORMAL_STATE 
27 NORMAL_STATE Announce timeout timer expired a. Transition to IDLE_STATE and flush 
unicast MAC address learning table 
28 NORMAL_STATE Announce frame from different a. Restart announce timeout timer 
ring supervisor MAC address than b. Save new active supervisor MAC address, 
active ring supervisor is received VLAN ID and sequence count 
uporly oF port? c. Ifring state in Announce frame is 
RING_FAULT_STATE, transition to 
FAULT_STATE and flush unicast MAC 
address learning table 
d. Else, stay in NORMAL_STATE 
29 NORMAL_STATE Locate_Fault frame received from a. Ignore 
active ring supervisor 
30. NORMAL_STATE Neighbor_Check_Request or a. Ignore 
Neighbor_Check_Response frame 
received on port | or port 2 
31 NORMAL_STATE Sign_On frame received on port 1 a. Add node data to participant list and send 
frame through port 2 
32 NORMAL_STATE Sign_On frame received on port 2 a. Add node data to participant list and send 
frame through port 1 
33 IDLE_STATE Flush_Tables frame received a. Ignore 
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Event No. Current State Event Action(s) 


34 NORMAL_STATE Flush_Tables frame received a. Flush unicast and multicast MAC address 
learning tables 

b. If Learning Update Enable field in 
Flush_Tables frame is set to TRUE, send 
Learning_Update frame 


35 FAULT_STATE Flush_Tables frame received a. Flush unicast and multicast MAC address 
learning tables 

b. If Learning Update Enable field in 
Flush_Tables frame is set to TRUE, send 
Learning_Update frame 


Notes: 
e Network Topology attribute shall be updated at events 1, 2, 10, 12, 13 and 27 to appropriate value. 
e@ Network Status attribute shall be updated at events 1, 2, 7, 9, 10, 11, 12, 13, 24, 25, 26, 27 and 28 to appropriate value. 


9-5.10.3. Ring Supervisor 


Figure 9-5.14 State Transition Diagram for Ring Supervisor 
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Table 9-5.24 Parameter Values for Ring Supervisor Node 


Parameter Value 
Active supervisor precedence Default 0 or as configured 
Active supervisor MAC address As manufactured 
Ring protocol VLAN ID Default 0 or as configured 
Beacon interval duration Default 400 microseconds or as configured 
Beacon timeout duration Default 1960 microseconds or as configured 
Announce suppression duration 2 times Beacon Timeout 
Announce interval duration 1 second 


Active supervisor precedence (Backup) Obtained from Beacon frame 


Active supervisor MAC address Obtained from Beacon frame 
(Backup) 

Ring protocol VLAN ID (Backup) Obtained from Beacon frame 
Beacon timeout duration (Backup) Obtained from Beacon frame 
Neighbor check timeout duration 100 milliseconds 

Maximum retry limit for 3 (total number of tries) 


Neighbor_Check_Request frame 


Switchover quiet period duration during | 1 beacon timeout duration of last active ring supervisor 
ring supervisor switchover 


Sign on timeout duration 60 seconds 


The following notes apply to the State-Event-Action table: 


e LastBcnRevPort is a bit string variable used to track port(s) on which last Beacon frame was 
received, with the following bit definitions: 


Bit Description 


0 | Set if a beacon frame from the active supervisor has been received on Port 1 


1 | Set if a beacon frame from the active supervisor has been received on Port 2 
2-N | Not used; set to 0 


e MAC address 1 1-22-33-44-55-66 shall be encoded as 0x112233445566 for numerical 
comparison in case of supervisor precedence tie. 

e Nodes not configured as ring supervisor or acting as back up ring supervisor shall statically 
configure unicast MAC address of current active ring supervisor into unicast MAC learning 
table to be forwarded only through both ring ports. 

e If the attributes of an active supervisor such as beacon interval duration, beacon timeout 
duration, precedence and VLAN ID are changed, then the active supervisor must follow 
special behavior before applying new values. If the active supervisor was in 
NORMAL_STATE (Active), then it should stop all timers, leave port 2 in blocked state 
and stop sending beacon and announce frames for 2 times (current) beacon timeout 
duration. If the active supervisor was in FAULT_STATE (Active), then it should stop all 
timers, leave port 2 in forwarding state and stop sending beacon and announce frames for 2 
times (current) beacon timeout duration. At the end of the wait period it should start from 
event 1 in table below. Refer also to section 9-5.5.2.7 (Changing Ring Parameters). 

e Ifa backup supervisor cannot support the currently active Beacon Interval and/or Beacon 
Timeout, the backup supervisor shall indicate the condition via the DLR Object, and shall 
not take over as active supervisor in the event of a ring reconfiguration. 
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e If the precedence attribute of a backup supervisor is reconfigured online to a higher value 
than current active ring supervisor, then it should stop all timers and start from event | in 
table below immediately. Refer also to section 9-5.5.2.7 (Changing Ring Parameters). 

e If anon-supervisory is node is enabled as a ring supervisor online and the configured 
precedence value is higher than current active ring supervisor, then it should stop all timers 
and start from event 1 in table below immediately. For all other changes, it should just stay 
as a backup supervisor in current state. 

e The active ring supervisor shall not forward multicast frames with destination address 
01:80:C2:00:00:00 (BPDU) from one ring port to other, irrespective of ring state. However, 
if the active ring supervisor has non-ring ports, it shall forward said multicast frames 
between those non-ring ports and between only one ring port and those non-ring ports. 


Table 9-5.25 State-Event-Action Table for Ring Supervisor Node 


Event 


Current State Event Action(s) 


None Power up a. Initialize 

b. If not configured as ring supervisor transition to 
IDLE_STATE and return 

Else, set LastBcnRevPort to 0 

Enable forwarding of all frames on both ports 
Transition to FAULT_STATE (Active) 

Send Beacon frame through both ports and start 
beacon interval timer 


mean 


g. Start announce interval timer with announce 
suppression duration 


IDLE_STATE Beacon frame from a ring a. Save as active supervisor precedence, MAC 

supervisor received on port 1 address, VLAN ID and beacon timeout duration 

b. Set LastBenRevPort to 1 

c. Start beacon timeout timer for port 1 

d. Transition to FAULT_STATE (Backup) and 
flush unicast MAC address learning table 


IDLE_STATE Beacon frame from a ring a. Save as active supervisor precedence, MAC 

supervisor received on port 2 address, VLAN ID and beacon timeout duration 

b. Set LastBcnRevPort to 2 

c. Start beacon timeout timer for port 2 

d. Transition to FAULT_STATE (Backup) and 
flush unicast MAC address learning table 


IDLE_STATE Link lost on port I a. Stop forwarding frames on port | 


IDLE_STATE Link lost on port 2 a. Stop forwarding frames on port 2 


IDLE_STATE Link restored on port 1 a. Start forwarding frames on port 1 


IDLE_STATE Link restored on port 2 a. Start forwarding frames on port 2 


wlrafalul se 


IDLE_STATE Frame from self received on port |__| a. Do not forward frame on network and drop it 
or port 2 
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Current State 


Event 


Action(s) 


9 IDLE_STATE 


Locate_Fault or 
Neighbor_Check_Request or 
Neighbor_Check_Response or 
Sign_On frame or Link_Status 
frame or Neighbor_Status frame 
received on port | or port 2 or 
Verify_Fault_Location service 
request received 


a. 


Ignore 


10 FAULT_STATE 
(Active) 


Beacon interval timer expired 


Send Beacon frame through both ports and start 
beacon interval timer 


11 FAULT_STATE 
(Active) 


Beacon frame from self received 
on port 1 


Set LastBcenRevPort to (LastBenRevPort | 0x1) 


. Restart beacon timeout timer for port | 


If LastBenRevPort is not equal to 3, return 


. Else, stop neighbor check timeout timers for 


both ports 

Block all traffic on port 2 except for special ring 
protocol frames 

Transition to NORMAL_STATE (Active) and 
flush unicast MAC address learning table 


. Send Announce frame on port | and restart 


announce interval timer with announce interval 
duration 


. Send Beacon frame on both ports and restart 


beacon interval timer 


Send Sign_On frame on port | and start sign on 
timeout timer 


12 FAULT_STATE 
(Active) 


Beacon frame from self received 
on port 2 


aogep 


Set LastBcnRevPort to (LastBcnRevPort | 0x2) 


. Restart beacon timeout timer for port 2 


If LastBenRevPort is not equal to 3, return 


|. Else, stop neighbor check timeout timers for 


both ports 
Block all traffic on port 2 except for special ring 
protocol frames 


Transition to NORMAL_STATE (Active) and 
flush unicast MAC address learning table 


. Send Announce frame on port | and restart 


announce interval timer with announce interval 
duration 


. Send Beacon frame on both ports and restart 


beacon interval timer 


Send Sign_On frame on port | and start sign on 
timeout timer 
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Current State 


Event 


Action(s) 


FAULT_STATE 
(Active) 


Beacon frame from different 
supervisor MAC address than self 
received on port 1 


If new supervisor has lower precedence (or 
numerically lower MAC address in case of tie) 
than self: 

i. If embedded switch hardware determines 
precedence, drop the new Beacon frame 
and return 

ii. If embedded switch hardware does not 
determine precedence, the new Beacon 
frame shall be forwarded on the other 
ring port and to the host; the host CPU. 
shall ignore the new Beacon frame and 
reurn 

Else, stop beacon interval timer, stop beacon 

timeout timers for both ports, stop neighbor 

check timeout timers for both ports and stop 
announce interval timer 

Save new active supervisor precedence, MAC 

address, VLAN ID and beacon timeout 


Set LastBcenRevPort to 1 

Start beacon timeout timer for port I 
Transition to FAULT_STATE (Backup) and 
flush unicast MAC address learning table 


FAULT_STATE 
(Active) 


Beacon frame from different 
supervisor MAC address than self 
received on port 2 


Tf new supervisor has lower precedence (or 
numerically lower MAC address in case of tie) 
than self: 

i. If embedded switch hardware determines 
precedence, drop the new Beacon frame 
and return 

ii. If embedded switch hardware does not 
determine precedence, the new Beacon 
frame shall be forwarded on the other 
ring port and to the host; the host CPU 
shall ignorer the new Beacon frame and 
return 

Else, stop beacon interval timer, stop beacon 

timeout timers for both ports, stop neighbor 

check timeout timers for both ports and stop 
announce interval timer 

Save new active supervisor precedence, MAC 

address, VLAN ID and beacon timeout 

Set LastBcnRevPort to 2 

Start beacon timeout timer for port 2 


Transition to FAULT_STATE (Backup) and 
flush unicast MAC address learning table 


FAULT_STATE 
(Active) 


Beacon timeout timer expired for 
port 1 


Set LastBcnRevPort to (LastBcnRevPort & 
~Ox1) 


FAULT_STATE 
(Active) 


Beacon timeout timer expired for 
port 2 


Set LastBcnRevPort to (LastBcnRevPort & 
~Ox2) 


FAULT_STATE 
(Active) 


Link lost on port 1 


Save self as last active node on port 1 
Stop forwarding frames on port 1 


FAULT_STATE 
(Active) 


Link lost on port 2 


Save self as last active node on port 2 
Stop forwarding frames on port 2 
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ree Current State Event Action(s) 
19 FAULT_STATE Link restored on port 1 Start forwarding frames on port 1 
(Active) 
20 FAULT_STATE Link restored on port 2 Start forwarding frames on port 2 
(Active) 
21 FAULT_STATE Link_Status frame received on port . If Link_Status frame does not report a link 
(Active) 1 failure, drop frame and return 
. Else, save source node as last active node on 
port 1 
22 FAULT_STATE Link_Status frame received on port . If Link_Status frame does not report a link 
(Active) 2 failure, drop frame and return 
. Else, save source node as last active node on 
port 2 
23 FAULT_STATE Neighbor_Status frame received on . If Neighbor_Status frame does not report a 
(Active) port | neighbor node failure, drop frame and return 
. Else, save source node as last active node on 
port 1 
24 FAULT_STATE Neighbor_Status frame received on . If Neighbor_Status frame does not report a 
(Active) port 2 neighbor node failure, drop frame and return 
. Else save source node as last active node on 
port 2 
25 FAULT_STATE Announce interval timer expired Send Announce frame through both ports and 
(Active) start announce interval timer with announce 
interval duration 
26 FAULT_STATE Verify_Fault_Location service Send Locate_Fault frame on port 1 and port 2 
(Active) request received b. If link is active on port 1, clear neighbor status 
for port 1, send Neighbor_Check_Request 
frame on port 1 and start neighbor check 
timeout timer for port 1 
. Else, save self as last active node on port 1 
d. If link is active on port 2, clear neighbor status 
for port 2, send Neighbor_Check_Request 
frame on port 2 and start neighbor check 
timeout timer for port 2 
. Else, save self as last active node on port 2 
27 FAULT_STATE Neighbor_Check_Request frame Send Neighbor_Check_Response frame on port 
(Active) received on port 1 1 
28 FAULT_STATE Neighbor_Check_Request frame . Send Neighbor_Check_Response frame on port 
(Active) received on port 2 2 
29 FAULT_STATE Neighbor_Check_Response frame Stop neighbor check timeout timer for port 1 
(Active) received on port 1 and save neighbor status for port 1 
30 FAULT_STATE Neighbor_Check_Response frame Stop neighbor check timeout timer for port 2 
(Active) received on port 2 and save neighbor status for port 2 
31 FAULT_STATE Neighbor check timer timeout on . If number of retries have not exceeded 


(Active) 


port | 


maximum limit, send Neighbor_Check_Request 
on port | and start neighbor check timeout timer 
for port 1 


. Else, save self as last active node on port 1 
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Event 


No. Current State Event Action(s) 
32 FAULT_STATE Neighbor check timer timeout on a. If number of retries have not exceeded 
(Active) port 2 maximum limit, send Neighbor_Check_Request 
on port 2 and start neighbor check timeout timer 
for port 2 
b. Else, save self as last active node on port 2 
33 FAULT_STATE Sign_On frame received on port 1 a. Ignore 
(Active) or port 2 
34 NORMAL_STATE | Beacon interval timer expired a. Send Beacon frame through both ports and start 
(Active) beacon interval timer 
35 NORMAL_STATE | Beacon frame from self received a. Restart beacon timeout timer for port 1 
(Active) on port 1 
36 NORMAL_STATE | Beacon frame from self received a. Restart beacon timeout timer for port 2 
(Active) on port 2 
37 NORMAL_STATE | Beacon frame from different a. If new supervisor has lower precedence (or 
(Active) supervisor MAC address than self numerically lower MAC address in case of tie) 
received on port 1 than active supervisor: 

i. If embedded switch hardware determines 
precedence, drop the new Beacon frame 
and return 

ii. If embedded switch hardware does not 
determine precedence, the new Beacon 
frame shall be forwarded on the other 
ring port and to the host; the host CPU 
shall ignore the new Beacon frame and 
return 

b. Else, stop beacon interval timer, stop beacon 
timeout timers for both ports, stop announce 
interval timer and stop sign on timeout timer 

c. Enable forwarding of all frames on port 2 

d. Save new active supervisor precedence, MAC 
address, VLAN ID and beacon timeout 
duration 

e. Set LastBcnRevPort to | 

f. Start beacon timeout timer for port 1 

g. Transition to FAULT_STATE (Backup) and 


flush unicast MAC address learning table 
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Current State 


Event 


Action(s) 


NORMAL_STATE 
(Active) 


Beacon frame from different 
supervisor MAC address than self 
received on port 2 


If new supervisor has lower precedence (or 

numerically lower MAC address in case of tie) 

than active supervisor: 

i. If embedded switch hardware determines 
precedence, drop the new Beacon frame 
and return 


ii, If embedded switch hardware does not 
determine precedence, the new Beacon 
frame shall be forwarded on the other 
ring port and to the host; the host CPU 
shall ignore the new Beacon frame and 
return 

Else, stop beacon interval timer, stop beacon 

timeout timers for both ports, stop announce 

interval timer and stop sign on timeout timer 

Enable forwarding of all frames on port 2 

Save new active supervisor precedence, MAC 

address, VLAN ID and beacon timeout 

duration 

Set LastBenRevPort to 2 

Start beacon timeout timer for port 2 

Transition to FAULT_STATE (Backup) and 

flush unicast MAC address learning table 


39 


NORMAL_STATE 
(Active) 


Beacon timeout timer expired for 
port 1 


ae oe 


0 


Stop sign on timeout timer 

Set LastBenRevPort to 2 

Enable forwarding of all frames on port 2 
Transition to FAULT_STATE (Active) and 
flush unicast MAC address table 

Send Announce frame on both ports and restart 
announce interval timer with announce interval 
duration 

Send Beacon frame and restart beacon interval 
timer 

Send Locate_Fault frame 

Clear neighbor status for port 1 and 2, send 
Neighbor_Check_Request for port | and 2, and 


start neighbor check timeout timer for port 1 
and 2 


40 


NORMAL_ STATE 
(Active) 


Beacon timeout timer expired for 
port 2 


asses 


Stop sign on timeout timer 

Set LastBenRevPort to 1 

Enable forwarding of all frames on port 2 
Transition to FAULT_STATE (Active) and 
flush unicast MAC address table 

Send Announce frame on both ports and restart 
announce interval timer with announce interval 
duration 

Send Beacon frame and restart beacon interval 
timer 

Send Locate_Fault frame 

Clear neighbor status for port 1 and 2, send 
Neighbor_Check_Request for port 1 and 2, and 


start neighbor check timeout timer for port 1 
and 2 
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Event 
No. 


Current State 


Event 


Action(s) 


41 


NORMAL_ STATE 
(Active) 


Link lost on port I 


see se 


Save self as last active node on port 1 

Stop sign on timeout timer 

Set LastBenRevPort to 2 

Enable forwarding of all frames on port 2 
Transition to FAULT_STATE (Active) and 
flush unicast MAC address table 

Send Announce frame on both ports and restart 
announce interval timer with announce interval 
duration 

Send Beacon frame and restart beacon interval 
timer 


a2 


NORMAL_ STATE 
(Active) 


Link lost on port 2 


eae se 


Cc} 


Save self as last active node on port 2 

Stop sign on timeout timer 

Set LastBcenRevPort to 1 

Enable forwarding of all frames on port 2 
Transition to FAULT_STATE (Active) and 
flush unicast MAC address table 

Send Announce frame on both ports and restart 
announce interval timer with announce interval 
duration 

Send Beacon frame and restart beacon interval 
timer 


43 


NORMAL_STATE 
(Active) 


Link_Status frame received on port 
1 


If Link_Status frame does not report a link 
failure, drop frame and return 


Else, save source node as last active node on 
port 1 


Stop sign on timeout timer 


. Enable forwarding of all frames on port 2 


Transition to FAULT_STATE (Active) and 
flush unicast MAC address table 

Send Announce frame on both ports and restart 
announce interval timer with announce interval 
duration 

Send Beacon frame and restart beacon interval 
timer 


44 


NORMAL_STATE 
(Active) 


Link_Status frame received on port 
2 


If Link_Status frame does not report a link 
failure, drop frame and return 

Else, save source node as last active node on 
port 2 

Stop sign on timeout timer 


. Enable forwarding of all frames on port 2 


Transition to FAULT_STATE (Active) and 
flush unicast MAC address table 

Send Announce frame on both ports and restart 
announce interval timer with announce interval 
duration 

Send Beacon frame and restart beacon interval 
timer 


45 


NORMAL_STATE 
(Active) 


Neighbor status frame received on 
port | or port 2 


Ignore 
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Fre Current State Event Action(s) 
46 NORMAL_STATE | Announce interval timer expired a. Send Announce frame through port | and start 
(Active) announce interval timer with announce interval 
duration 
47 NORMAL_STATE | Verify_Fault_Location service a. Ignore 
(Active) request received 
48 NORMAL_STATE | Neighbor_Check_Request or a. Ignore 
(Active) Neighbor_Check_Response frame 
received on port 1 or port 2 
49 NORMAL_STATE | Sign_On frame received on port 1 a. If first entry in participant list is not self, drop 
(Active) or port 2 frame and return 
b. Else, save ring participants count and 
participant list from frame and stop sign on 
timeout timer 
50 NORMAL_STATE. | Sign on timeout timer expired a. Send Sign_On frame through port | and start 
(Active) sign on timeout timer 
Sl FAULT_STATE Beacon frame from active ring a. Restart port 1 beacon timeout timer 
(Backup) supervisor received on port | and 
LastBenRevPort is 1 
52 FAULT_STATE Beacon frame from active ring a. Restart port 2 beacon timeout timer 
(Backup) supervisor received on port 2 and 
LastBenRevPort is 2 
53 FAULT_STATE Beacon timeout timer expired for a. If not configured as a ring supervisor, stop 
(Backup) port I and LastBenRevPort is 1 neighbor check timeout timers for both ports, 
transition to IDLE_STATE, flush unicast MAC 
address learning table and return 
b. Else, stop neighbor check timeout timers for 
both ports 
c. Wait for switchover quiet period duration 
d. Set LastBenRevPort to 0 
e. Enable forwarding of all frames on both ports 
f. Transition to FAULT_STATE (Active) 
g. Send Beacon frame through both ports and start 
beacon interval timer 
h. Start announce interval timer with announce 
suppression duration 
54 FAULT_STATE Beacon timeout timer expired for a. If not configured as a ring supervisor, stop 


(Backup) 


port 2 and LastBenRevPort is 2 


mmone 


neighbor check timeout timers for both ports, 
transition to IDLE_STATE, flush unicast MAC 
address learning table and return 


. Else, stop neighbor check timeout timers for 


both ports 
Wait for switchover quiet period duration 


. Set LastBcnRcvPort to 0 


Enable forwarding of all frames on both ports 
Transition to FAULT_STATE (Active) 


.. Send Beacon frame through both ports and start 


beacon interval timer 


|. Start announce interval timer with announce 


suppression duration 
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Event 


No. Current State Event Action(s) 
55 FAULT_STATE Beacon frame from active ring Set LastBenRevPort to 3 
(Backup) supervisor received on port 2 and | b, Start/reset port 2 beacon timeout timer 
LasticaRevPortis | . If the ring state of beacon frame is not 
RING_NORMAL_STATE, return 
. Else, stop neighbor check timeout timers for 
both ports 
. Transition to NORMAL_STATE (Backup) and 
flush unicast MAC address learning table 
56 FAULT_STATE Beacon frame from active ring Set LastBcnRevPort to 3 
(Backup) supervisor received on port | and b. Start/restart port 1 beacon timeout timer 
TastBenReve ort is:2 If the ring state of beacon frame is not 
RING_NORMAL_ STATE 
. Else, stop neighbor check timeout timers for 
both ports 
. Transition to NORMAL_STATE (Backup) and 
flush unicast MAC address learning table 
57. FAULT_STATE Beacon frame from different ring If new supervisor has lower precedence (or 


(Backup) 


supervisor MAC address than 
active ring supervisor is received 
on port 1 


numerically lower MAC address in case of tie) 

than active supervisor: 

i. If embedded switch hardware determines 
precedence, drop the new Beacon frame 
and return 

ii. If embedded switch hardware does not 
determine precedence, the new Beacon 
frame shall be forwarded on the other 
ring port and to the host; the host CPU 
shall ignore the new Beacon frame and 
return 

Else, stop beacon timeout timers for both ports 

Save new active supervisor precedence, MAC 

address, VLAN ID and beacon timeout 

duration 

Set LastBcnRevPort to 1 

Start beacon timeout timer for port 1 

Stay in FAULT_STATE (Backup) and flush 

unicast MAC address learning table 
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Event 


No. 


Current State 


Event 


Action(s) 


58 


FAULT_STATE 
(Backup) 


Beacon frame from different ring 
supervisor MAC address than 
active ring supervisor is received 
on port 2 


If new supervisor has lower precedence (or 
numerically lower MAC address in case of tie) 
than active supervisor: 

i. If embedded switch hardware determines 
precedence, drop the new Beacon frame 
and return 

ii. If embedded switch hardware does not 
determine precedence, the new Beacon 
frame shall be forwarded on the other 
ring port and to the host; the host CPU 
shall ignore the new Beacon frame and 
return 

Else, stop beacon timeout timers for both ports 


Save new active supervisor precedence, MAC 
address, VLAN ID and beacon timeout 
duration 


Set LastBcnRevPort to 2 
Start beacon timeout timer for port 2 


Stay in FAULT_STATE (Backup) and flush 
unicast MAC address learning table 


59 


FAULT_STATE 
(Backup) 


Link lost on port 1 and 
LastBenRevPort is 1 


meme ao 


If not configured as a ring supervisor, stop 
neighbor check timeout timers for both ports, 
stop beacon timeout timers for both ports, 
transition to IDLE_STATE, flush unicast MAC 
address learning table and return 

Else, stop neighbor check timeout timers for 
both ports and stop beacon timeout timers for 
both ports 

Wait for switchover quiet period duration 

Set LastBenRevPort to 0 

Enable forwarding of all frames on both ports 
Transition to FAULT_STATE (Active) 

Send Beacon frame through both ports and start 
beacon interval timer 

Start announce interval timer with announce 
suppression duration 


60 


FAULT_STATE 
(Backup) 


Link lost on port 1 and 
LastBenRevPort is 2 


Send Link Status frame to active ring supervisor 


61 


FAULT_STATE 
(Backup) 


Link lost on port 2 and 
LastBenRevPort is 2 


me meas 


If not configured as a ring supervisor, stop 
neighbor check timeout timers for both ports, 
stop beacon timeout timers for both ports, 
transition to IDLE_STATE, flush unicast MAC 
address learning table and return 

Else, stop neighbor check timeout timers for 
both ports and stop beacon timeout timers for 
both ports 

Wait for switchover quiet period duration 

Set LastBcnRevPort to 0 

Enable forwarding of all frames on both ports 
Transition to FAULT_STATE (Active) 

Send Beacon frame through both ports and start 
beacon interval timer 

Start announce interval timer with announce 
suppression duration 
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pee Current State Event Action(s) 
62 FAULT_STATE Link lost on port 2 and a. Send Link Status frame to active ring supervisor 
(Backup) LastBenRevPort is 1 
63 FAULT_STATE Link restored on port 1 a. Start forwarding frames on port 1 
(Backup) 
64 FAULT_STATE Link restored on port 2 a. Start forwarding frames on port 2 
(Backup) 
65 FAULT_STATE Locate_Fault frame received from a. If link is not active on port 1 or port 2 send 
(Backup) active ring supervisor on port 1 or Link_Status frame to active ring supervisor 
port 2 b. Else clear neighbor status for port | and 2, send 
Neighbor_Check_Request for port | and 2, and 
start neighbor check timeout timer for port 1 
and 2. 
66 FAULT_STATE Neighbor_Check_Request frame a. Send Neighbor_Check_Response frame on port 
(Backup) received on port 1 1 
67 FAULT_STATE Neighbor_Check_Request frame a. Send Neighbor_Check_Response frame on port 
(Backup) received on port 2 2 
68 FAULT_STATE Neighbor_Check_Response frame | a. Stop neighbor check timeout timer for port 1 
(Backup) received on port 1 and save neighbor status for port | 
69 FAULT_STATE Neighbor_Check_Response frame | a. Stop neighbor check timeout timer for port 2 
(Backup) received on port 2 and save neighbor status for port 2 
70 FAULT_STATE Neighbor check timer timeout on a. If number of retries have not exceeded 
(Backup) port 1 maximum limit, send Neighbor_Check_Request 
on port I and start neighbor check timeout timer 
for port 1 
b. Else, send Neighbor_Status frame to active ring 
supervisor 
71 FAULT_STATE Neighbor check timer timeout on a. If number of retries have not exceeded 
(Backup) port 2 maximum limit, send Neighbor_Check_Request 
on port 2 and start neighbor check timeout timer 
for port 2 
b. Else, send Neighbor_Status frame to active ring 
supervisor 
72 FAULT_STATE Sign_On frame or Link_Status a. Ignore 
(Backup) frame or Neighbor_Status frame 
received on port | or port 2 or 
Verify_Fault_Location service 
request received 
73 NORMAL_STATE | Link lost on port 1 a. Send Link Status frame to active ring supervisor 
(Backup) b. Stop beacon timeout timer for port 1 
c. Set LastBcnRevPort to 2, transition to 
FAULT_STATE (Backup) and flush unicast 
MAC address learning table 
74 NORMAL_STATE J Link lost on port 2 a. Send Link Status frame to active ring supervisor 
(Backup) b. Stop beacon timeout timer for port 2 
c. Set LastBenRevPort to 2, transition to 
FAULT_STATE (Backup) and flush unicast 
MAC address learning table 


— 9-62 - 
Edition 1.18 


SINGLE SUBSCRIPTION ONLY; SUBSCRIPTION TERMS AND CONDITIONS OUTLINED ON PAGE (iii) 


Volume 2: EtherNet/IP Adaptation of CIP, Chapter 9: Indicators & Middle Layers 


pe Current State Event Action(s) 
75 NORMAL STATE | Beacon frame from active ring a. If the ring state of previous beacon frame 
(Backup) supervisor with received on port | was not 
RING_FAULT_STATE received RING_NORMAL_STATE, return 
on port 1 b. Else, stop beacon timeout timer for port 2 
c. Set LastBcenRevPort to 1, transition to 
FAULT_STATE (Backup) and flush unicast 
MAC address learning table 
76 NORMAL_STATE | Beacon frame from active ring a. Ifthe ring state of previous beacon frame 
(Backup) supervisor with received on port 2 was not 
RING_FAULT_STATE received RING_NORMAL_STATE, return 
on port 2 b. Else, stop beacon timeout timer for port 1 
c. Set LastBcenRevPort to 2, transition to 
FAULT_STATE (Backup) and flush unicast 
MAC address learning table 
Tt NORMAL_STATE | Beacon timeout timer expired for a. Set LastBcnRevPort to 2, transition to 
(Backup) port | FAULT_STATE (Backup) and flush unicast 
MAC address learning table 
78 NORMAL_STATE | Beacon timeout timer expired for a. Set LastBenRevPort to 1, transition to 
(Backup) port 2 FAULT_STATE (Backup) and flush unicast 
MAC address learning table 
719 NORMAL_STATE | Beacon frame from active ring a. Restart port 1 beacon timeout timer 
(Backup) supervisor received on port 1 
80 NORMAL_STATE | Beacon frame from active ring a. Restart port 2 beacon timeout timer 
(Backup) supervisor received on port 2 
81 NORMAL_STATE | Beacon frame from different ring a. _ If new supervisor has lower precedence (or 
(Backup) supervisor MAC address than numerically lower MAC address in case of tie) 
active ring supervisor is received than active supervisor: 
on port 1 i. If embedded switch hardware determines 
precedence, drop the new Beacon frame 
and return 
ii. If embedded switch hardware does not 
determine precedence, the new Beacon 
frame shall be forwarded on the other 
ring port and to the host; the host CPU 
shall ignore the new Beacon frame and 
return 
b. Else, stop beacon timeout timers for both ports 
c. Save new active supervisor precedence, MAC 
address, VLAN ID and beacon timeout 
duration 
d. Set LastBcnRevPort to 1 


Start beacon timeout timer for port 1 


Transition to FAULT_STATE (Backup) and 
flush unicast MAC address learning table 
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re Current State Event Action(s) 
82 NORMAL_STATE | Beacon frame from different ring a. If new supervisor has lower precedence (or 
(Backup) supervisor MAC address than numerically lower MAC address in case of tie) 
active ring supervisor is received than active supervisor: 
on port 2 i. If embedded switch hardware determines 
precedence, drop the new Beacon frame 
and return 
ii. If embedded switch hardware does not 
determine precedence, the new Beacon 
frame shall be forwarded on the other 
ring port and to the host; the host CPU 
shall ignore the new Beacon frame and 
return 
b. Else, stop beacon timeout timers for both ports 
c. Save new active supervisor precedence, MAC 
address, VLAN ID and beacon timeout 
duration 
d. Set LastBenRevPort to 2 
e. Start beacon timeout timer for port 2 
f. — Transition to FAULT_STATE (Backup) and 
flush unicast MAC address learning table 
83 NORMAL_STATE | Locate_Fault frame or a. Ignore 
(Backup) Neighbor_Check_Request frame or 
Neighbor_Check_Response frame 
or Link_Status frame or 
Neighbor_Status frame received on 
port | or port 2 or 
Verify_Fault_Location service 
request received 
84 NORMAL_STATE | Sign_On frame received on port 1 a. If first entry in participant list is self, drop frame 
(Backup) and return 
b. Else, add node data to participant list and send 
frame on port 2 
85 NORMAL_STATE | Sign_On frame received on port 2 a. If first entry in participant list is self, drop frame 
(Backup) and return 
b. Else, add node data to participant list and send 
frame on port 1 
86 IDLE_STATE Flush_Tables frame received a. Ignore 
87 NORMAL_STATE_ | Flush_Tables frame received a. Flush unicast and multicast MAC address 
(Active) learning tables 
b. If Learning Update Enable field in 
Flush_Tables frame is set to TRUE, send 
Learning_Update frame 
88 FAULT_STATE Flush_Tables frame received a. Flush unicast and multicast MAC address 
(Active) learning tables 
b. If Learning Update Enable field in 
Flush_Tables frame is set to TRUE, send 
Learning_Update frame 
89 NORMAL_STATE | Flush_Tables frame received a. Flush unicast and multicast MAC address 
(Backup) learning tables 
b. If Learning Update Enable field in 


Flush_Tables frame is set to TRUE, send 
Learning_Update frame 
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Event 


No. Current State Event Action(s) 


90 


FAULT_STATE Flush_Tables frame received a. Flush unicast and multicast MAC address 

(Backup) learning tables 

b. If Learning Update Enable field in 
Flush_Tables frame is set to TRUE, send 
Learning_Update frame 


Notes: 


Network Topology attribute shall be updated at events 1, 2, 3, 53, 54, 59 and 61 to appropriate value. 

Network Status attribute shall be updated at events 1, 2, 3, 8, 11, 12, 13, 14,37, 38, 39, 40, 41, 42, 43, 44, 53,54, 55, 56, 
57, 58, 59, 61, 73, 74, 75, 76, 77, 78, 81 and 82 to appropriate value. 

Ring Supervisor Status attribute shall be updated at events 1, 13, 14, 37, 38, 53, 54, 59 and 61 to appropriate value. 

Ring Faults Count attribute shall be updated at events 1, 13, 14, 37, 38, 39, 40, 41, 42, 43, 44, 53, 54, 59, 61 to appropriate 
value. 

Last Active Node | attribute shall be updated at events 1, 11, 12, 13, 14, 17, 21, 23, 26, 31, 41 and 43 to appropriate value. 
Last Active Node 2 attribute shall be updated at events 1, 11, 12, 13, 14, 18,22, 24, 26, 32, 42 and 44 to appropriate value. 
Ring Protocol Partcipants Count attribute shall be updated at events 1, 13, 14, 37, 38 and 49 to appropriate value. 

Ring Protocol Partcipants List attribute shall be updated at events 1, 13, 14, 37, 38 and 49 to appropriate value. 

If in events 11 and 12, Beacon frames are received continuously for more than 3 consecutive beacon timeout durations on 
same port without the other port receiving any Beacon frames, then that constitutes a partial network fault condition. When 
such a condition is detected, the active ring supervisor shall block all traffic on port 2 resulting in network segmentation 
and update network status attribute. This condition requires user intervention to resolve. The location of fault can be 
identified through Verify_Fault_Location service. 

If in events 39, 40, 41, 42, 43, 44 the supervisor detects that 5 faults have occurred in a 30 second period, the supervisor 
shall remain in FAULT_STATE and block all traffic on port 2. Such a condition must be explicitly cleared by the user via 
the Clear_Rapid_Faults service of the DLR Object. 


9-5.1 


0.4 Redundant Gateway 


Figure 9-5.15 State Transition Diagram for Redundant Gateway 
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Table 9-5.26 Parameter Values for Redundant Gateway Node 


Parameter Value 
Active gateway Precedence Default 0 or as configured 
Active gateway MAC address As manufactured 
Advertise Interval duration Default 2000 microseconds or as configured 
Advertise Timeout duration Default 5000 microseconds or as configured 
Learning Update Enable Default TRUE or as configured 
Active Listen Timeout duration 1 times Advertise Timeout duration 
Active gateway Precedence (Backup) Obtained from Advertise frame 
Active gateway MAC address (Backup) Obtained from Advertise frame 
Learning Update Enable (Backup) Obtained from Advertise frame 
Advertise Interval duration (Backup) Obtained from Advertise frame 
Advertise Timeout duration (Backup) Obtained from Advertise frame 


The following notes apply to the State-Event-Action table: 


e MAC address 11-22-33-44-55-66 shall be encoded as 0x112233445566 for numerical 
comparison in case of gateway Precedence tie. 

e If the attributes of an active gateway such as Advertise Interval duration, Advertise Timeout 
duration, Precedence and Learning Update Enable are changed, the active gateway must 
follow special behavior before applying new values. It should block traffic forwarding 
between DLR ports and uplink ports, stop all timers and stop sending Advertise frames for 

.5 times old Advertise Timeout duration. At the end of wait period it should start from 

event | in table below. 

e Ifabackup gateway cannot support the currently active Advertise Interval and/or Advertise 

Timeout, the backup gateway shall indicate the condition via the DLR Object, and shall not 

take over as active gateway in the event of a gateway switchover. 

e Ifthe Precedence attribute of a backup gateway is reconfigured online to a higher value than 

current active gateway, then it should stop all timers and start from event | in table below 

immediately. 

e Unlike other DLR frames, an active gateway device shall forward the Learning_Update 

rames to uplink ports when traffic forwarding is enabled between DLR ports and uplink 

ports. 

e Anactive gateway device in ACTIVE_NORMAL_STATE shall declare partial network 
fault, if it receives Advertise frame with ACTIVE_NORMAL_STATE as gateway state 
from another active gateway device with lower Precedence (or numerically lower MAC 
address in case of a tie). Upon declaring partial network fault, it shall transition to 
FAULT_STATE, it shall stop all timers, shall stop sending Advertise frames and shall block 
traffic forwarding between DLR ports and uplink ports. It shall indicate the condition 
through the Redundant Gateway Status attribute in DLR object. It shall set the Active 
Gateway Address and Active Gateway Precedence attributes to that of the other active 
gateway with lower precedence. When the user clears the condition through 
Clear_Gateway_Partial_Fault service, the gateway shall clear the condition and start from 
event | in table below. 

e When a gateway switchover occurs, the new active gateway device shall send the topology 
change notification message on its uplink ports that is appropriate for the protocol currently 
enabled on its uplink ports. This requirement does not apply if no protocol is currently 
enabled on its uplink ports. 
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Table 9-5.27 State Evemt Action Table for Redundant Gateway Node 


Event Current State Event Action(s) 
No. 
1 None Power up Initialize 
Block traffic forwarding between DLR ports and uplink 
ports 
Transition to IDLE_STATE 
2 IDLE_STATE Redundant gateway Start active listen timer for Active Listen Timeout 
enabled duration 
Send Advertise frame with ACTIVE_LISTEN_STATE 
as gateway state 
Start advertise interval timer with Advertise Interval 
duration 
Transition to ACTIVE_LISTEN_STATE 
3. ACTIVE_LISTEN_STATE Advertise frame from Save active gateway MAC address, Precedence, 
another active gateway | Advertise Interval and Timeout and Learning Update 
with higher Precedence | Enable fields 
(or numerically higher | Stop advertise interval timer 
MAC address in case of | sip active listen timer 
a tie) is received and anaes aT _— 
gateway state field in Start advertise timeout timer with Advertise Timeout 
frame is not set to duration 
FAULT_STATE Transition to BACKUP_LNORMAL_STATE 
4 ACTIVE_LISTEN_STATE Advertise interval timer | Send Advertise frame 
expired Restart advertise interval timer with Advertise Interval 
duration 
5 ACTIVE_LISTEN_STATE Active listen timer Send Advertise frame with 
expired ACTIVE_NORMAL_ STATE as gateway state 
Restart advertise interval timer with Advertise Interval 
duration 
Enable traffic forwarding between DLR ports and uplink 
ports 
Send Flush_Tables frame to all DLR nodes 
Send Learning_Update frame if Learning Update Enable 
attribute of DLR Object is TRUE 
Transition to ACTIVE_NORMAL_STATE 
6 ACTIVE_LISTEN_STATE Uplink connection or Send Advertise frame with FAULT_STATE as gateway 


higher level failure 


state 

Stop advertise interval timer 

Stop active listen timer 

Start advertise timeout timer with Advertise Timeout 
duration 


Transition to FAULT_STATE 
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Event Current State Event Action(s) 
No. 

7 ACTIVE_NORMAL_STATE Advertise frame from Save active gateway MAC address, Precedence, 
another active gateway | Advertise Interval and Timeout and Learning Update 
with higher Precedence | Enable fields 
(or numerically higher | Stop advertise interval timer 
MAC address in case of | start advertise timeout timer with Advertise Timeout 
a tie) is received and duration 

ateway state field i 
rancid ae hak = Block traffic forwarding between DLR ports and uplink 
FAULT_STATE Ports 
Transition to BACKUP_NORMAL_STATE 

8 ACTIVE_NORMAL_STATE Advertise interval timer | Send Advertise frame 
expired Restart advertise interval timer with Advertise Interval 

duration 

9 ACTIVE_NORMAL_STATE Uplink connection or Send Advertise frame with FAULT_STATE as gateway 
higher level failure state 

Stop advertise interval timer 

Start advertise timeout timer with Advertise Timeout 
duration 

Block traffic forwarding between DLR ports and uplink 
ports 

Transition to FAULT_STATE 

10 FAULT_STATE Uplink connection Start advertise timeout timer with Advertise Timeout 
restored and active duration 
gateway has higher Transition to BACKUP_NORMAL_STATE 
Precedence (or 
numerically higher 
MAC address in case of 
a tie) 

11 FAULT_STATE Uplink connection Start active listen timer for Active Listen Timeout 
restored and active duration 
gateway has lower Send Advertise frame with ACTIVE_LISTEN_STATE 
Precedence (or as gateway state 
numerically lower Start advertise interval timer with Advertise Interval 
MAC address in case of | Gurati 
atie) uration 

Transition to ACTIVE_LISTEN_STATE 

12 FAULT_STATE Advertise frame from Restart advertise timeout timer with Advertise Timeout 
active gateway received | duration 

13 FAULT_STATE Advertise timer timeout | Save active gateway MAC address and Precedence as all 

Zeros 

14 FAULT_STATE Advertise frame from Save active gateway MAC address, Precedence, 
another active gateway | Advertise Interval and Timeout and Learning Update 
with higher Precedence | Enable fields 
than current active 
gateway (or 
numerically higher 
MAC address in case of 
a tie) is received and 
gateway state field in 
frame is not set to 
FAULT_STATE 

15 BACKUP_NORMAL_STATE | Uplink connection or Transition to FAULT_STATE 
higher level failure 
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Event Current State Event Action(s) 
No. 
16 BACKUP_NORMAL_STATE | Advertise frame from Restart advertise timeout timer with Advertise Timeout 
active gateway received | duration 
17 BACKUP_NORMAL_STATE_ | Advertise timer timeout | Send Advertise frame with ACTIVE_LISTEN_STATE 
as gateway state 
Start active listen timer with Active Listen Timeout 
duration 
Start advertise interval timer with Advertise Interval 
duration 
Transition to ACTIVE_LISTEN_STATE 
18 BACKUP_NORMAL_STATE Advertise frame from Save active gateway MAC address, Precedence, 
another active gateway | Advertise Interval and Timeout and Learning Update 
with higher Precedence | Enable fields 
than current active Restart advertise timeout timer with Advertise Timeout 
gateway (or duration 
numerically higher 
MAC address in case of 
a tie) is received and 
gateway state field in 
frame is not set to 
FAULT_STATE 
Notes: 


Redundant gateway status attribute shall be updated on events 2, 3, 6, 7, 9, 10, 11, 15 and 17 to appropriate value 


9-5.11 Performance Analysis 


The example performance calculations below uses following key parameters/assumptions: 


Variable Description 

NumNodes Number of nodes in ring network, 50 for example. 

BenFrmDly Delay due to a beacon frame in store and forward switching, 7 microseconds (64 byte 
frame with on wire overhead) for example. 

AvgEipFrmDly Delay due to average EtherNet/IP frame, 12 microseconds (128 byte frame with on 
wire overhead) for example. 

MaxFrmDly Delay due to maximum size Ethernet frame, 124 microseconds (1522 byte frame with 
on wire overhead) for example. 

MaxDlyNodePrent Percentage of number of nodes in ring on which beacon will be delayed by maximum 


size Ethernet frame, 10% for example. 


IntSwtchDly 


Internal switching delay on every node, 5 microseconds for example. 


WirePrpgtDly Signal propagation delay on 100 meters of copper media, 1 microsecond for example. 

NodeProcDly Processing delay on nodes for responding to ring frames and events, 25 microseconds 
for example. 

BenIntrvl Beacon interval, should be less than half of the fastest connection RPI, 400 


microseconds for example. 


In order to provide predictable performance for network fault detection and reconfiguration all 
nodes directly on ring must dedicate highest priority queue to ring protocol frames and must 
implement strict priority scheduling for highest priority queue. With such a configuration, a 
ring protocol frame will encounter at most one lower priority frame delay on each node. For 
performance analysis, assume that all links on network operate at 1O0OMbps speed and in full 


duplex mode. 
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Ring Beacon frames are 64 bytes long including FCS and have an on wire overhead of 20 bytes 
of which 8 bytes are for preamble and start of frame delimiter pattern and 12 bytes are for inter 
frame gap. Ring Beacon frames with 20 byte on wire overhead take approximately BcnFrmDly 
= 7 microseconds on wire. 


Assume that ring Beacon frames will be delayed on most nodes by a lower priority frame with 
an average size of 128 bytes including FCS. In a network with mostly EtherNet/IP traffic, on 
some nodes ring Beacon frames may not be delayed at all, in some other nodes they may be 
delayed by 256 byte frames and in some others it may be delayed by frames between these two 
extremes, for an average of 128 bytes. A 128 byte frame with 20 byte on wire overhead takes 
approximately AvgEipFrmDly = 12 microseconds on wire. 

Assume that the nodes use store and forward switching architecture and that each node has an 
average internal switching overhead delay of IntSwtchDly = 5 microseconds. Assume 
propagation delay for copper media of 100 meters to be WirePrpgtDly = 1 microsecond. The 
total typical delay per node for ring Beacon frames is therefore 


TypcelDlyPerNode = BcnFrmDly + AvgEipFrmDly + IntSwtchDly + WirePrpgtDly 
TypcelDlyPerNode = 7 + 12 +5 + 1 = 25 microseconds. 


Assume that the ring Beacon frames would also be delayed on MaxDlyNodePrent = 10% of 
nodes by maximum sized Ethernet frames of 1522 bytes each or some combination of large 
frames on more than 10% of nodes that is equal to 10% of nodes with maximum sized frames. 
Such frames may be present on network for any reason including configuration, HMI, web etc. 
A 1522 byte frame with 20 byte on wire overhead takes approximately MaxFrmDly = 124 
microseconds on wire. The total maximum delay per node for ring Beacon frames on these 
nodes is therefore 


MaxDlyPerNode = BenFrmDly + MaxFrmDly + IntSwtchDly + WirePrpgtDly 
MaxDlyPerNode = 7 + 124 + 5 + 1 = 137 microseconds. 


For a ring network comprised of NumNodes = 50 nodes, total maximum round trip time for 
Beacon frames is therefore 


MaxRndTripTime = (NumNodes * (1 — MaxDlyNodePrent) * TypclDlyPerNode) + 
(NumNodes * MaxDlyNodePrent * MaxDlyPerNode) 
MaxRndTripTime = (50 * (1 — 0.1) * 25) + (50 * 0.1 * 137) = 1810 microseconds 


For same network, minimum delay per node is when Beacon frame is not delayed by any other 
frame and therefore 


MinDlyPerNode = BenFrmDly + IntSwtchDly + PrpgtDly 
MinDlyPerNode = 7 + 5 + 1 = 13 microseconds 


For a ring network comprised of NumNodes = 50 nodes, total minimum round trip time is 
therefore 


MinRndTripTime = NumNodes * MinDlyPerNode 
MinRndTripTime = 13 * 50 = 650 microseconds. 
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In general, lower beacon interval provides faster ring recovery performance. Beacon interval 
should be less than half of the fastest connection RPI in the network to prevent connection 
timeouts. Assume a beacon interval of BenIntrvl = 400 microseconds which constitutes 1.75% 
of network bandwidth and is suitable for high performance CIP motion connections with | 
millisecond RPI and also works for slower I/O connections. 


For choosing beacon timeout, consider a first Beacon frame transmitted at time Tx, facing 
minimum round trip time delay and arriving at active supervisor ports at time Rx, = Tx, + 
MinRndTripTime = Tx; + 650 microseconds. Assume that a second Beacon frame transmitted 
at time Tx, = Tx, + BenIntrvl = Tx; + 400 microseconds is lost on route due to frame 
corruption. A third Beacon frame transmitted at time Tx; = Tx. + BenIntrvl = Tx. + 400 
microseconds facing maximum roundtrip delay will arrive at active supervisor ports at time Rx; 
= Tx; + MaxRndTripTime = Tx; + 1810 microseconds. The maximum arrival delay of third 
Beacon frame on active supervisor ports after first Beacon frame is therefore equal to Rx; — 
Rx; = (Tx3 + 1810) - (Tx; + 650) = (Tx; + 400 + 400 + 1810) — (Tx; + 650) = 1960 
microseconds. Hence the beacon timeout duration should be equal to BenTimeout = 1960 
microseconds. 


Assume end node processing delay of NodeProcDly = 25 microseconds for responding to ring 
frames or events. 


For the network described, following will be the worst case performance for ring nodes that 
rely on Beacon frame mechanism: 


1. Faults that are detectable in physical layer: This is the most common type of faults. The 
worst case scenario happens when the fault occurs half way across ring network from active 
ring supervisor. It will take half round trip time for Link Status frames to reach from 
neighboring nodes of fault to active ring supervisor. It will take another half round trip time 
for Beacon frame with FAULT_STATE from active supervisor to reach farthest node or for 
ring nodes to timeout Beacon frames whichever happens earlier. End node processing delay 
is involved for three times, once at fault neighbor, once at supervisor and once at farthest 
node. The total worst case delay is therefore 


PhysclLyrFltDlyBen = (2 * 0.5 * MaxRndTripTime) + (3 * NodeProcDly) 
PhysclLyrFltDlyBen = 1810 + (3 * 25) = 1885 microseconds. 


2. Faults that are not detectable in physical layer: This type of faults is relatively rare. The 
worst case scenario happens when the fault occurs half way across ring network from active 
ring supervisor. It will take half round trip time for last Beacon frame from near fault 
location to reach active ring supervisor. It will take another beacon timeout period for active 
supervisor and ring nodes to timeout Beacon frames. End node processing delay is involved 
once at all nodes. The total worst case delay is therefore 


NonPhysclLyrFltDlyBen = (0.5 * MaxRndTripTime) + BenTimeout + NodeProcDly 
NonPhysclLyrFltDlyBen = (0.5 * 1810) + 1960 + 25 = 2890 microseconds. 


3. Network restoration to normal mode of operation: It is equal to a total of one beacon interval 
for a beacon to be generated, one maximum round trip time for beacon and another half 
maximum round trip time for Beacon frame with RING_NORMAL_STATE to reach 
farthest node. End node processing delay is involved twice, once at ring supervisor and once 
at all nodes. The total worst case delay is therefore 


RingRstrDlyBen = BenIntrvl + (1.5 * MaxRndTripTime) + (2 * NodeProcDly) 
RingRstrDlyBen = 400 + (1.5 * 1810) + (2 * 25) = 3165 microseconds. 
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For the network described, following will be the worst case performance for ring nodes that 
rely on Announce frame mechanism: 


1. Faults that are detectable in physical layer: This is the most common type of faults. The 
worst case scenario happens when the fault occurs half way across ring network from active 
ring supervisor. It will take half round trip time for Link Status frames to reach from 
neighboring nodes of fault to active ring supervisor. It will take another half round trip time 
for Announce frame with FAULT_STATE from active ring supervisor to reach farthest 
node. End node processing delay is involved for three times, once at fault neighbor, once at 
supervisor and once at farthest node. The total worst case delay is therefore 


PhysclLyrFltDlyAnnc = (2 * 0.5 * MaxRndTripTime) + (3 * NodeProcDly) 
PhysclLyrFitDlyAnnc = 1810 + (3 * 25) = 1885 microseconds. 


2. Faults that are not detectable in physical layer: This type of faults is relatively rare. The 
worst case scenario happens when the fault occurs half way across ring network from active 
ring supervisor. It will take half round trip time for last Beacon frame from near fault 
location to reach active ring supervisor. It will take another beacon timeout period for active 
supervisor to timeout Beacon frames. It will take another half round trip time for Announce 
frame with FAULT_STATE from active supervisor to reach farthest node. End node 
processing delay is involved twice, once at supervisor and once at end node. The total worst 
case delay is therefore 


NonPhysclLyrFltDly Anne = (2 * 0.5 * MaxRndTripTime) + BcnTimeout + (2 * 
NodeProcDly) 


NonPhysclLyrFltDlyAnnc = 1810 + 1960 + (2 * 25) = 3820 microseconds. 


3. Network restoration to normal mode of operation: It is equal to a total of one beacon interval 
for a beacon to be generated, one maximum round trip time for beacon and another 
maximum round trip time for Announce frame to reach farthest node. End node processing 
delay is involved twice, once at supervisor and once at end node. Note that this is the total 
delay for an Announce based node to flush its unicast MAC table. The ring would have been 
restored earlier per calculation for Beacon based nodes. The total worst case delay is 
therefore 


RingRstrDly Anne = BenIntrvl + (2 * MaxRndTripTime) + (2 * NodeProcDly) 
RingRstrDly Anne = 400 + (2 * 1810) + (2 * 25) = 4070 microseconds. 


Based on similar calculations Table 9-5.28 below provides configuration parameters and worst 
case performance numbers for different ring network node numbers. It should be noted that 
though these performance numbers will work for most cases, deviation from assumptions 
outlined above will require recalculation of numbers based on procedure described above. For 
example, if any link in ring is set to operate at 1OMbps speed and/or half duplex mode the 
numbers must be adjusted (for 10Mbps, multiply by 10). 
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Table 9-5.28 Example Ring Configuration Parameters and Performance 


Non- Non- 
physical physical cs . 
4 Layer Layer (tu LA 
Physical Restore Restore 
R Faults Faults 
ound Layer Delay for Delay for 
Number | Beacon Tri Beacon Recovery Recovery 
& rip a Faults Beacon Announce 
of Ring | Interval soit Timeout Delay for Delay for 
Time Recovery frame frame 
Nodes (usecs) (usecs) Beacon Announce 
(usecs) Delay 1 Based Based 
Frame Frame 
(usecs) Nodes Nodes 
Based Based (Geen) (529) 
Nodes Nodes 
(usecs) (usecs) 
25 400 905 1380 980 1858 2335 1808 2260 
50. 400 1810 1960 1885 2890 3820 3165 4070 
(nominal 
network 
size) 
100 400 3620 3120 3695 4955 6790 5880 7690 
150 400 5430 4280 5505 7020 9760 8595 11310 
200 400 7240 5440 7315 9085 12730 11310 14930 
250 400 9050 6600 9125 11150 15700 14025 18550 
1 Same for Beacon and Announce frames based nodes. 
Important: When non-DLR nodes are present in the ring, recovery and restoration delays are 
as they are for Announce-based nodes, provided the non-DLR nodes follow the requirements 
specified in section 9-5.5. If non-DLR nodes don’t follow the requirements, recovery and 


9-5.11.1 


restoration delays are unpredictable. 


When using non-DLR switches in the ring, unicast packet loss may occur, as described in 
section 9-5.7.3, Non-DLR Switches. 


Redundant Gateway Switchover Performance 


The example performance calculations below use following key parameters/assumptions: 


Table 9-5.29 Variables for Performance Analysis 


Variable Description 
NodeProcDly Processing delay on nodes for responding to ring frames and events, 25 
microseconds for example. 
MaxRndTripTime 1810 microseconds for 50 nodes from section 9-5.11 
AdvrtsIntrv1 Advertise Interval, should be more than MaxRndTripTime, 2000 


microseconds for example. 


AdvrtsTimeout 


Advertise Timeout, should be 2.5 times AdvrtsIntrv1, 5000 microseconds 
for example. 


ActiveListenTimeout 


Equal to 1 times AdvrtsTimeout, 5000 microseconds for example. 


LearnUpdtPropDly 


Learning update frame propagation delay through DLR to non-DLR. 
switches outside DLR network, should be greater than 
MaxRndTripTime, assume 5000 microseconds for example. 
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Redundant gateway switchover performances for three different cases of failure, assuming 
Learning Update Enable has been set to TRUE, are as follows: 


1. Uplink connection failure detected by active gateway at physical layer: 13.745 milliseconds 


This is the most common type of faults. The active gateway will detect physical layer failure 
and will send an Advertise frame with FAULT_STATE. It may take MaxRndTripTime for 
the Advertise frame to reach backup gateway device. The backup gateway device will take 
ActiveListenTimeout to enable traffic forwarding and send Flush_Tables frame. 
Flush_Tables frame may take MaxRndTripTime to reach farthest DLR node. Farthest DLR 
node will send Learning_Update frame which may take LearnUpdtPropDly to update non- 
DLR switches outside DLR network. End node processing delays are involved for 5 times 
in total. The total worst case delay is therefore 


GtwyPhysclLyrFltDly = (2 * MaxRndTripTime) + ActiveListenTimeout + 
LearnUpdtPropDly + (5 * NodeProcDly) = (2 * 1810) + 5000 + 5000 + (5 *25) = 13745 


microseconds. 
2. Active gateway failure: 18.695 milliseconds 


Active gateway might fail just after sending last Advertise frame. It may take 
MaxRndTripTime to reach backup gateway device. The backup gateway device will wait 
for AdvrtsTimeout before declaring active gateway as lost. The backup gateway device will 
further take ActiveListenTimeout to enable traffic forwarding and send Flush_Tables frame. 
Flush_Tables frame may take MaxRndTripTime to reach farthest DLR node. Farthest DLR 
node will send Learning_Update frame which may take LearnUpdtPropDly to update non- 
DLR switches outside DLR network. End node processing delays are involved for 3 times 
in total. The total worst case delay is therefore 


GtwyFailDly = (2 * MaxRndTripTime) + AdvrtsTimeout + ActiveListenTimeout + 
LearnUpdtPropDly + (3 * NodeProcDly) = (2 * 1810) + 5000 + 5000 + 5000 + (3 *25) = 
18695 microseconds. 


3. Higher layer uplink fault detection: 6.013745 seconds 


A higher layer uplink failure (e.g. something other than a link failure reported by the PHY) 
might be detected by active gateway through a protocol (e.g., RSTP) on uplink ports. This 
case depends on that protocol’s high layer fault detection performance. For example with 
RSTP, the delay to detect a higher layer fault could be as high as 6 seconds (with typical 
defaults) to timeout RSTP hello frames. Once detected additional delays are same as 
GtwyPhysclLyrFltDly, since same set of actions need to take place. The total worst case 
delay for RSTP is therefore 


GtwyRstpLyrFitDly = RstpFltDly + GtwyPhysclLyrFltDly = 6000000 + 13745 = 6013745 
microseconds. 
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9-6 
9-6.1 


9-6.2 


9-7 
9-7.1 


9-7.2 


RSTP Protocol 
Introduction 


The Rapid Spanning Tree Protocol (RSTP) was originally designed for networks based on a 
tree topology where many devices are connected back to an Ethernet switch which in turn can 
be connected to other Ethernet switches. RSTP is a mature and widely accepted approach to 
solve the Ethernet ring recovery issue when one looks at the most current enhancements to the 
specification. The IEEE Standard 802.1D 2004 edition incorporated RSTP into that part of the 
standard. Changes were made by the IEEE Standards committee to RSTP that make it a 
suitable recovery mechanism for a ring topology for some automation applications. 


This section describes RSTP as a network high availability solution. An RSTP object interface 
is defined for EtherNet/IP to support devices that have multiple Ethernet ports and embedded 
switch technology. 


Details specific to the RSTP objects can be found in CIP Volume 2 Section 5-10 -RSTP 
Bridge Object and Section 5-11 RSTP Port Object. 


RSTP Overview 


The Rapid Spanning Tree Protocol (RSTP) is a link layer (OSI Layer 2) network protocol. By 
configuring the Port State of each Bridge Port in the Bridged LAN, RSTP ensures that the 
stable connectivity provided by each Bridge between its Ports and by the individual LANs to 
which those Ports attach is predictable, manageable, full, simple, and symmetric. RSTP further 
ensures that temporary loops in the active topology do not occur if the network has to 
reconfigure in response to the failure, removal, or addition of a network device. 


For more information about RSTP, refer to Section 17 Rapid Spanning Tree Protocol (RSTP) 
of IEEE 802.1D-2004. 


Parallel Redundancy Protocol (PRP) 
Introduction 


The IEC 62439 series considers two classes of network redundancy: redundancy managed 
within the network; and redundancy managed in the end nodes. 


Further improvements in recovery time require managing of redundancy in the end nodes, by 
equipping the end nodes with several, redundant communication links. In general, doubly 
attached end nodes provide sufficient redundancy. In this type of redundancy, no assumption 
about the switches within the LAN is made. 


For time-critical applications such as synchronized drives, the parallel operation of disjoint 
networks provides a seamless recovery, but requires complete duplication of the network. 
Some critical plants also require doubly attached nodes in order to cope with a failure of an 
Ethernet link between an end node and the LAN. 


PRP Overview 


The PRP redundancy protocol implements redundancy in the devices such as Double attached 
nodes implementing PRP (DANPs) and Redundancy Boxes (Red Box). 


A DANP is attached to two independent Local Area Networks (LANs) of similar topology 
(LAN_A and LAN_B) which operate in parallel. One DANP (a source) sends the same frame 
over both LANs to another DANP (Destination) who receives it from both LANs, consumes 
the first frame and discards the duplicate. 
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The mechanism of duplicate generation and rejection can be implemented by a Red-Box. A 
Red-Box does the transition between a Singly Attached Node (SAN) and the doubled LANs 
(LAN_A and LAN_B). The Red-Box mimics the SANs connected behind it (called VDAN or 
virtual DANs) and multicasts supervision frames on their behalf. The Red-Box is itself a 
DANP and has its own IP address for management purposes, but it may also perform 
application functions. 


Figure 9-7.1 shows a redundant network consisting of two switched LANs, which can have any 
topology, e.g. tree, ring or mesh. 


Figure 9-7.1 PRP Network 


4 2 


The two LANs are identical in protocol at the MAC-LLC level, but they can differ in 
performance and topology. Transmission delays may also be different, especially if one of the 
networks reconfigures itself, e.g. using RSTP, to overcome an internal failure. 


The two LANs follow configuration rules that allow the network management protocols such 
as Address Resolution Protocol (ARP) to operate correctly. 


The two LANs shall have no connection between them and are assumed to be fail-independent. 
Redundancy can be defeated by single points of failure, such as a common power supply or a 
direct connection whose failure brings both networks down. Refer to the installation guidelines 
in the IEC 62439-3 standard (IEC 62439-3:2012-7) to provide guidance to the installer to 
achieve fail-independence. 


PRP is not defined in the CIP specification but defined in the sub-clauses 4 and 7 of the IEC 
62439-3 standard (IEC 62439-3:2012-7). The sub-clause reference does not exclude the use of 
Precision Time Protocol (PTP-IEEE 1588-2008) with PRP. The CIP specification provides 
configuration and monitoring with the definition of the following CIP objects: Parallel 
Redundancy Protocol (PRP) Object, and PRP Nodes Table Object. 
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10-1 Introduction 


This chapter of the EtherNet/IP specification contains additions to the definition of CIP 
bridging and routing that are EtherNet/IP specific. At this time, no such additions exist. 
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A-1 Introduction 


This chapter of the EtherNet/IP specification contains additions to the definition of CIP explicit 
messaging services that are EtherNet/IP specific. At this time there are no such additions. 
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B-1 Introduction 


This chapter of the EtherNet/IP specification contains additions to the definition of CIP error 
codes that are EtherNet/IP specific. At this time there are no such additions. 
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Introduction 


This chapter of the EtherNet/IP specification contains additions to the CIP Data Management 
specification that are EtherNet/IP specific. At this time there are no such additions. 
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Introduction 


This chapter of the EtherNet/IP specification contains additions to the list of CIP engineering 
units that are EtherNet/IP specific. At this time, there are no such additions. 


—~D-3- 
Edition 1.18 
SINGLE SUBSCRIPTION ONLY; SUBSCRIPTION TERMS AND CONDITIONS OUTLINED ON PAGE (iii) 


Volume 2: EtherNet/IP Adaptation of CIP, Appendix D: Engineering Units 


This page is intentionally left blank 


_D-4— 
Edition 1.18 
SINGLE SUBSCRIPTION ONLY; SUBSCRIPTION TERMS AND CONDITIONS OUTLINED ON PAGE (iii) 


Volume 2: EtherNet/IP Adaptation of CIP, Appendix E: EtherNet/IP QuickConnect™ 


Volume 2: EtherNet/IP Adaptation of CIP 


Appendix E: EtherNet/IP QuickConnect ™ 
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E-1 


Introduction 


In many automotive applications, robots, tool changers and framers are required to quickly 
exchange tooling fixtures which contain a section or segment of an industrial network. This 
requires the network and nodes to be capable of quickly connecting and disconnecting, both 
mechanically, and logically. 


While the mechanical means for connecting and disconnecting tooling exists, achieving a quick 
re-establishment of a logical network connection between a network controller and a fully 
powered-down node on Ethernet can take as much as 10 or more seconds. This is too slow for 
applications that require very short cycle times. 


The time in which a robot arm first makes electrical contact with a new tool, until the 
mechanical lock being made, is typically 1 second. In applications where the tools are 
constantly being connected and disconnected, the nodes need to be able to achieve a logical 
connection to the controller and test the position of the tool in less than 1 second from the time 
the tool and the robot make an electrical connection. This means that the node needs to be able 
to power up and establish a connection in approximately 500 ms. This section discusses the 
requirements and optimizations necessary for the controller and the QuickConnect target node 
that may affect the overall logical connection time on an EtherNet/IP network when physically 
connecting and disconnecting. 


It should be noted that controller and robotic application behavior is outside the scope of this 
specification. 


The QuickConnect feature is an option enabled on a node-by-node basis. When enabled, the 
QuickConnect feature will direct EtherNet/IP target devices to quickly power up and join an 
EtherNet/IP network. 


In order for QuickConnect devices to power up as quickly as possible, the following list of 
recommendations for QuickConnect device manufacturers should be followed. 


e¢ Minimize the hardware delay at power-up and reset as much as possible. 

e Design devices with embedded switches and (at least) 2 external Ethernet ports, so that 
devices may be deployed in a linear topology to eliminate the start up time of a separate 
switch on the tool. 

e Optimize power up self-test routines and LED tests. 


The QuickConnect feature is enabled within a target device through the non-volatile 
EtherNet/IP QuickConnect attribute (12) in the TCP/IP object. A device shall have this feature 
disabled as the factory default. See section 5-3.3.2.11. 


The goal for QuickConnect connection time is 500ms. Specifically, this is defined as the 
guaranteed repeatable time between the electrical contact of power and Ethernet signals at the 
tool changer, and when the newly connected devices are ready to send the first CIP I/O data 
packet. 
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QuickConnect connection time is comprised of several key time durations. The majority of the 
QuickConnect connection time is due to the QuickConnect target devices’ power-up time. 
Also contributing to the connection time is the amount of time it takes a controller to detect the 
newly attached device and send a Forward Open to start the connection process. The overall 
500ms QuickConnect connection time is additive, and consists of the QuickConnect devices’ 
power-up time, the controller’s connection establishment time, and actual network 
communication time. Also, the network communication time is dependent on the network 
topology. For instance, in a linear topology, the network communication time will be 
dependent on all devices powering up, plus the delay through all of the devices. The final 
application connection time assumes that connections to ALL of the I/O devices on the tool 
have been established. 


The following figure shows the events, states, and sequence in which a controller shall 
discontinue communications with a device on a given tool and then establish a connection to a 
device on a new tool. Note: There can be multiple I/O devices on the tool. This sequence is 
repeated for each connection from the controller to the I/O devices on the tool. 


Figure E-1.1 QuickConnect System Sequence Diagram (application behavior steps are in red) 
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In Figure E-1.1, actions marked by * are the typical application actions, but may vary and are 
outside the scope of the spec. Refer to section E-3 for specific requirements and actions of the 
controller. 


There shall be two classes of QuickConnect devices. 


e Class A QuickConnect target devices shall be able to power-up, send the first Gratuitous 
ARP packet, and be ready to accept a TCP connection in <= 350ms. 

e Class B QuickConnect target devices shall be able to power-up, send the first Gratuitous 
ARP packet, and be ready to accept a TCP connection in <= 2 seconds. 
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EtherNet/IP Target Requirements 


EtherNet/IP target devices supporting QuickConnect shall adhere to the following 
requirements. 


Power-up diagnostics and LED tests may be delayed as needed in order to meet the desired 
startup time. Diagnostics may be performed in the background after startup 
QuickConnect devices shall implement the ability to set forced speed/duplex mode (for 
10/100 Mb Ethernet at least), via the Ethernet Link Object. It is recommended that users 
set forced speed and duplex mode on all of a device's ports during QuickConnect device 
commissioning in order to meet the fastest QuickConnect timing requirements. 
When in QuickConnect mode, a port configured for forced speed and duplex mode, 
QuickConnect devices shall not use Auto-MDIX (detection of the required cable 
connection type). This detection may take more time than the allotted QuickConnect 
system connection time. To enable the use of straight-thru cables when Auto-MIDX is 
disabled, the following rules shall be applied: 
1. On a device with only one port: the port shall be configured as MDI. 
2. On devices with 2 external Ethernet ports: 

a. The labels for the 2 external ports shall include an ordinal indication (e.g.: Port 

1 and Port 2, or A and B). 
b. The port with the lower ordinal indication shall be configured as MDI. 
c. The port with the upper ordinal indication shall be configured as MDIX. 


Note: For DLR capable devices this requirement overrides the requirement that DLR 
capable devices shall have "forced Auto-MDIX" when speed & duplex are fixed. 


The target device shall support EtherNet/IP QuickConnect attribute (12) in the TCP/IP 
Object that enables the QuickConnect feature. See section 5-3.3.2. 

The target device shall have the QuickConnect keywords and values included in the 
device’s EDS file. See section 7-7.1. 
When a QuickConnect target’s I/O connection is closed via a Forward Close, the target 
shall close the TCP connection after sending the Forward Close Response. It is important 
to clean up resources before powering down so that a new connection can be quickly 
established with the replacement node by the controller. Having the target device close the 
TCP connection, as opposed to the originator, forces a timelier cleanup of resources in the 
originator needed for the next quick connection establishment. In this scenario, the 
EtherNet/IP encapsulation session is also cleaned up. 

When the target device is ready to join the network, it shall issue a gratuitous ARP which 
will cause any needed update to the ARP table of the controller for that IP address. 
Because ARP is not a guaranteed service it may be necessary to send multiple gratuitous 
ARP messages to ensure that the controller’s ARP cache is updated. The device shall 
continue to issue the gratuitous ARP every 25ms for a maximum of 40 times (1 second), 
until an I/O connection is established. 
When the QuickConnect feature is enabled, if IPv4 Address Conflict Detection (see 
Volume 2, Appendix F) is supported and enabled, the device shall skip the initial Address 
Probing and Address Announcement phases and enter the Ongoing Conflict Detection 
phase immediately after putting the IP address in use (refer to Figure E-2.1 and Figure F- 
1.1). All other aspects of IPv4 Address Conflict Detection behavior shall be as specified in 
Volume 2, Appendix F. The ACD state machine shall run independent of the 
QuickConnect startup behavior shown in Figure E-2.1. 
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Important: As a consequence of skipping initial address probing, a QuickConnect device 
whose IP address conflicts with an existing device may disrupt communications to the existing 
device. The user must assume responsibility for ensuring that no nodes exist with the same IP 
address and that no more than one connection originator is configured to access the same 
QuickConnect device. 


Figure E-2.1 shows the typical target device power-up logic as it pertains to QuickConnect. 
Note that interaction with IPv4 Address Conflict Detection is applicable only if the device 
supports IPv4ACD. 
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Figure E-2.1 Typical Target 
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E-3 Controller Requirements 


e An EtherNet/IP controller device that participates in QuickConnect connection 
establishment shall have the QuickConnect keywords and values included in its EDS file. 
See Table 7-7.2 
e Ina QuickConnect system, the controller must have the capability to open and close 
connections to the QuickConnect target devices based on system events. For example, two 
such system events might be: 
1. When the controller is done with a given tool (set of IP addresses on the tool) 
2. When the controller needs to enable connections to the new tool (set of IP addresses on 
the “new” tool) when it receives the electrical lock input signal from the tool changer 
indicating that the “new” tool was in place. 
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F-1 


F-1.1 


F-1.2 


Introduction 


Address conflict detection (ACD) is a mechanism that EtherNet/IP devices can use to detect 
and act upon IPv4 address conflicts. The ACD mechanism deployed in EtherNet/IP conforms 
to the IETF RFC 5227. 


The requirements specified in RFC 5227 are included by reference except where superseded by 
normative statements herein. This section also specifies additional requirements for 
EtherNet/IP devices with respect to the IPv4 ACD mechanism. 


e ACD is RECOMMENDED for EtherNet/IP devices. 

e An EtherNet/IP device, implementing ACD, SHALL conform to the ACD mechanism 
specified in IETF RFC 5227 except where superseded by normative statements herein. 

e An EtherNet/IP device, executing ACD, SHALL execute the ACD mechanism regardless 
of the method used by the device for obtaining its IP parameter set. 

e An EtherNet/IP device, executing ACD, and not executing the QuickConnect algorithm 
SHALL execute the ACD mechanism before using an IP parameter set. 

e EtherNet/IP Devices SHALL respond to ARP Probes. 


Overview of ACD 
The IPv4 ACD mechanism described by RFC 5227 involves the following activities: 


e Initial Address Probing & Conflict Detection: Before using an IP address the device issues 
ARP Probes to detect whether the address is in use by another device. 

e Address Announcement: An ARP Request packet is sent after determination that there are 
no IP address conflicts. 

¢ Ongoing Conflict Detection: Ongoing process that is in effect for as long as a device is 
using an IP Address. 

e AddressDefense: Procedure used to resolve an address conflict. 


The following sections specify additional requirements for EtherNet/IP devices that implement 
the ACD mechanism. 


ACD Behavior 


The principles of operation for the ACD mechanism are specified in IETF RFC 5227. Of 
particular note is the RFC 5227 requirement from section 2.1 that “... a host implementing this 
specification MUST test to see if the address is already in use ... when a link-state change 
signals that an Ethernet cable has been connected ...” 


In addition, this CIP volume further refines the ACD behavior description in the following 
ways: 
e The activities of ACD are grouped into regions, namely 
e Active Phase, 
e Passive Phase and 
e Semi-Active Phase. 
e Amore complete set of link_up transitions are included in the diagram. 
e Both single port and multi-port devices are accommodated. 


An EtherNet/IP device SHALL implement the ACD mechanism with the behavior specified in 
Figure F-1.1. 
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Figure F-1.1 ACD Behavior 
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F-1.2.1 


F-1.2.2 


F-1.2.3 


F-1.2.4 


IPv4 ACD Timing Constants 


Section 1.1 of RFC 5227 specifies a number of timing-related constants. Some of these 
constants are not optimal for EtherNet/IP applications and networks. In particular, the start-up 
delays caused by the ARP Probe intervals would be unacceptable in the industrial setting. 
Adaptation of the specified alternate values is consistent with section 1.3 of RFC 5227 on 
Applicability. 

EtherNet/IP devices that provide ACD SHALL implement the following values for the 
parameters defined in section 1.1 of RFC 5227. 


e¢ PROBE_WAIT 200 ms (initial random delay) 

e PROBE _NUM 4 (number of probe packets) 

e PROBE _MIN 200 ms (minimum delay until repeated probe) 

e PROBE_MAX 200 ms (maximum delay until repeated probe) 

e ANNOUNCE_WAIT 200 ms (delay before announcing) 

e ANNOUNCE_INTERVAL 2 sec (delay between announce packets) 

e DEFEND_INTERVAL 2 sec (minimum interval between defensive ARPs) 

Devices SHALL comply with the timing in RFC 5227 as modified by this Appendix within 
+10%. Notice that PROBE_MIN and PROBE_MAxX being set to the same value represents 
the CIP recommendation to use a fixed interval between probes rather than the 
recommendation in RFC 5227, section 2.1.1 Probe Details that subsequent probes after the 
initial probe be randomized between PROBE_MIN and PROBE_MAX. 


ProbeIpv4Address 

See sections 2.1 and 2.1.1 of IETF RFC 5227. 
Announcelpv4A ddress 

See section 2.3 of IETF RFC 5227. 


When the device has sent its first ARP Announcement it SHALL transition to 
OngoingDetection. If no conflict is detected within ANNOUNCE_INTERVAL seconds, then 
the device SHALL complete the send of its second ARP Announcement asynchronously with 
other network operations. 


WaitLinkIntegrity 


The WaitLinkIntegrity activity waits for the occurrence of a LinkUp event from an Ethernet 
port. 
This activity is initiated in two scenarios. 


e One is when a single port device experiences a LinkDown event. 
e The other is when a multi-port device experiences a LinkDown event and all of its other 
Ethernet ports are also down. 


When a LinkUp event occurs the ProbeIpv4 Address activity is then initiated. 


When a device detects that Ethernet link integrity has been lost and then regained (e.g., the 
network cable has been removed and replaced), the device SHALL restart the initial 
Probelpv4Address activity. 
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F-1.2.5 


F-1.2.6 


F-1.2.7 


Notification & Fault Action 
See section 1 of IETF RFC 5227. 


Tn addition to RFC 5227 behavior, when an address conflict is detected, EtherNet/IP devices 
SHALL take the following fault actions: 


e Set the device state to Recoverable Fault (Module Status LED flashing red), and 
e Set the Network Status LED to solid red. 


There are 2 synchronization transitions between the ACD Notification & FaultAction activity 
and the QuickConnect activity diagram shown in Appendix E, Figure E-2.1. 


The QcSynch-AcdFaultNotification is a synchronization transition to the QuickConnect 
behavior diagram that occurs either when the ACD mechanism has a ConflictDetected fault 
from the ProbeIpAddress activity or a DefenseFailed fault from the DefendWithPolicyB 
activity. 

The QcSynch-AcdFaultNotificationProcessed is a synchronization transition from the 
QuickConnect behavior diagram to the Notification & FaultAction activity that occurs after 
QuickConnect has processed the previous AcdFaultNotification. 


AcquireNewIpv4Parameters 
See section 1 of IETF RFC 5227. 


After notification of the detection of an IPv4 Address conflict, the device may be designed to 
obtain or use an alternate IPv4 address. The design of this method and its resulting selection of 
IPv4 Parameters are vendor specific. 


If a LinkDown occurs on the last active port while in the AcquireNewIpv4Parameter activity, 
then the ACD process in Figure F-1.1, ACD Behavior SHALL terminate. The ACD process 
SHALL be restarted after at least one link has been reestablished and a valid IPv4 configuration 
has been acquired according to Figure 5-3.1 Diagram Showing the Behavior of the TCP/IP 
Object. 


Notice also that EtherNet/IP devices SHALL limit the rate at which they probe for new 
candidate addresses using MAX_CONFLICTS and RATE_LIMIT_INTERVAL as defined in 
IETF RFC 5227 section 2.1.1. 


OngoingDetection 
See section 2.4 of IETF RFC 5227. 


The QcSynch-StartAcdWithQc is a synchronization transition with the QuickConnect behavior 
diagram shown in Appendix E, Figure E-2.1. If QuickConnect is enabled in the device, the 
activity for ACD begins at this point. 


The ACD mechanism as specified in IETF RFC 5227 section 2.1 states that “A host must not 
perform this check periodically as a matter of course”, indicating that periodic ARP Probes 
must not be sent as part of ongoing detection. However it has been observed that periodic ARP 
Probes allow the module to detect conflicts with devices that may not have been connected to 
the network at the time of initial probing, or when switches have dropped the initial ARP 
Probes due to initial forwarding delay. Therefore, EtherNet/IP devices that provide the ACD 
algorithm SHOULD issue periodic ARP Probes during ongoing detection. 
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EtherNet/IP devices that support periodic ARP Probes during ongoing detection SHALL use a 
transmission delay in the range of ONGOING_PROBE_MIN and ONGOING_PROBE_MAX 
using the values below. These values are not defined in IETF RFC 5227. Devices SHALL NOT 
exceed this specified range by more than 10% on either end. 


¢ ONGOING_PROBE_MIN 90 seconds (minimum interval for ongoing probes) 
¢ ONGOING_PROBE_MAX 150 seconds (maximum interval for ongoing probes) 


Tt is RECOMMENDED that the initial transmission delay for the first periodic ARP Probe has 
a pseudo-random value within the range of ONGOING_PROBE_MIN and 
ONGOING_PROBE_MAX. (“randomized” using the Ethernet MAC address as shown by 
example in F-1.2.10 below). The transmission delay for subsequent periodic ARP Probes need 
not be randomized, and may, for example, select the center value (120 seconds). 


F-1.2.8 DefendWithPolicyB 
See section 2.4 of IETF RFC 5227. 


“Address Conflict Detection is not limited to only the time of initial 
interface configuration, when a host is sending ARP Probes. Address 
Conflict Detection is an ongoing process that is in effect for as 
long as a host is using an address.” [RFC 5227 sec 2.4] 


After an IP address has successfully been probed and put into use, a device SHALL perform 
ongoing conflict detection and defense according to RFC 5227. 


If an address conflict is detected, the device SHALL defend its address per alternative (b) in 
RFC 5227 section 2.4. 


If a conflict persists as defined by RFC 5227) the device SHALL follow the behavior as when a | 
conflict is detected during initial probing (device state, LEDs, DHCP behavior, etc.) and 
execute the specified notification & fault actions. 


F-1.2.9 SemiActiveProbe 


[he SemiActiveProbe activity is initiated when a multi-port device receives a LinkUp event 
while other ports are still active. 


The SemiActiveProbe activity is a modified probing activity in which only two ARP probes are 
sent using probe delays of 200 ms. 


The SemiActiveProbe activity is defined to reduce the amount of ARP broadcast traffic that 
will be initiated from LinkUp activity on multi-port devices. 


F-1.2.10 Example Pseudo-random Delay Algorithm 


The following is an Xorshift Random Number Generator (RNG) algorithm that is based on the 
work of George Marsaglia from Florida State University '. 


This RNG is used to produce an initial pseudo-random delay before sending out the first 
periodic ARP probe based on the PROBE_WAIT value, and may also be used for determining 
the initial transmission delay the periodic ARP probes using the ONGOING_PROBE_MIN and 
ONGOING_PROBE_MAX values. 


' Xorshift RNGs, George Marsaglia, Florida State University, Journal of Statistical Software, Volume 8, Issue 14, 
http://www. jstatsoft.org/v08/il4/paper. 
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RFC 5227 requires that the device wait for a random time interval in the range zero to 
PROBE_WAIT. Assuming a PROBE_WAIT of 200 ms, then the RNG algorithm can be used 
to select an initial delay in the range of 0 to 200 ms using the following formula: 


Initial_Probe_Delay = PROBE_WAIT * R256 / 256. 
R256 is a random number in the range (0 .. 255) calculated using the algorithm below. 


The RNG algorithm uses an IEEE 802.3 MAC address, eg 12-34-56-78-9A-BC, written here in 
canonical notation. Canonical notation represents the order in which the bytes of the MAC 
address are transmitted, left to right, on the wire; i.e. 0x12 sent first, 0x34 sent next, and so on. 
The MAC address is mapped to an array, EnetAddr[], of 6 bytes as follows, using the example 
MAC address . 


EnetAddr[0] = 0x12; 
EnetAddr[1] = 0x34; 
EnetAddr[2] = 0x56; 
EnetAddr[3] = 0x78; 
EnetAddr[4] = 0x9A; 
EnetAddr[5] = OxBC; 


R256 is then calculated using the following Xorshift RNG. 


R256 = EnetAddr[0]; 

R256 = (R256 << 1 )* EnetAdadr{1]; 
R256 = (R256 << 1 ) * EnetAddr[2]; 
R256 = (R256 << 1 ) * EnetAddr[3]; 
R256 = (R256 << 1 ) * EnetAddr[4]; 
R256 = (R256 << 1 ) * EnetAddr[5]; 
R256 = R256 % 256; 


Where << is the left shift operator, “ is the exclusive OR operator, and % is the modulus 
operator. 
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G-1 


G-1.1 


I 


ntroduction 


3 


i 


The Internet Standard Management Framework defines a communications protocol, i.e. the 
Simple Network Management Protocol (SNMP) that provides services used to access data in 
Management Information Databases (MIB). The data in the MIB is defined and organized 
according to a data definition language called the Structure of Management Information (SMI). 


he data elements, i.e. the objects, in the MIB are referenced using Object Identifiers (OID) 


which are assigned at the time the MIB is designed. 
SNMP capability is provided using a client-server model where the SNMP component 


leployed in a node is called an SNMP Entity. [RFC 3411 sec 3.1] The SNMP Entity deployed 


at the client side is called the SNMP Manager and is defined in [3411 sec 3.1.3.1], while the 
SNMP Entity deployed at the server side is called the SNMP Agent and is defined in [3411 sec 


1.3.2] 


his section presents the requirements for providing an SNMP Agent in an EtherNet/IP device, 


.e. the server side of the architecture. 


Please note that the requirement level keywords, found in this appendix, conform to the 


efinitions found in the IETF RFC 2119. 


It is recommended that an EtherNet/IP device provides an SNMP Agent that conforms to the 
requirements stated in the remainder of this chapter. 


Implementation of the optional CIP SNMP Object (see Chapter 5) shall indicate that the 


levice’s SNMP Agent conforms to the requirements stated in this Appendix G. 


IETF RFC References 


RFC 1157, “A Simple Network Management Protocol (SNMP)”, May 1990 

RFC 1213 , “Management Information Base for Network Management of TCP/IP- based 
Internets: MIB-II, Mar 1991 

RFC 2011, “SNMPv2 Management Information Base for the Internet Protocol using 
SMIv2, Nov 1996 

RFC 2012, “SNMPv2 Management Information Base for the Transmission Control 
Protocol using SMIv2”, Nov 1996 

RFC 2013 , “SNMPv2 Management Information Base for the User Datagram Protocol 
using SMIv2, Nov 1996 

RFC 2578, “Structure of Management Information Version 2 (SMIv2)”, Apr 1999 

RFC 2579, “Textual Conventions for SMIv2”, Apr 1999 

RFC 2580, “Conformance Statements for SMIv2”, Apr 1999 

RFC 2863, “The Interfaces Group MIB”, Jun 2000 

RFC 3410, “Introduction and Applicability Statements for Internet Standard Management 
Framework”, Dec 2002 

RFC 3411, “An Architecture for Describing Simple Network Management Protocol 
(SNMP) Management Frameworks”, Dec 2002 

RFC 3412, “Message Processing and Dispatching for the Simple Network Management 
Protocol (SNMP), Dec 2002 

RFC 3413, “Simple Network Management Protocol (SNMP) Applications 

RFC 3414, “User-based Security Model (USM) for version 3 of the Simple Network 
Management Protocol (SNMP), Dec 2002 

RFC 3415, “View-based Access Control Model (VACM) for the Simple Network 
Management Protocol (SNMP), Dec 2002 
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e RFC 3416, “Version 2 of the Protocol Operations for the Simple Network Management 
Protocol (SNMP), Dec 2002 

e RFC 3417, “Transport Mappings for the Simple Network Management Protocol (SNMP), 
Dec 2002 

e RFC 3418, “Management Information Base (MIB) for the Simple Network Management 
Protocol (SNMP)’, Dec 2002 

e RFC 3584, “Coexistence between Version 1, Version 2, and Version 3 of the Internet- 
standard Network Management Framework”, Aug 2003 

e RFC 3635, “Definitions of Managed Objects for the Ethernet-like Interface Types”, Sep 
2003 


SNMP Agent 


The SNMP Agent provides the server side of the SNMP Management Framework. The SNMP 
Agent is responsible for receiving service requests from SNMP Managers, executing the 
indicated service which usually involves MIB access, and returning a service response to the 
SNMP Manager. 

The SNMP Agent also provides the sending of Notifications to one or more SNMP Managers. 
The sending of Notifications is triggered by the occurrence of certain events. Some 
Notifications and their associated trigger events are standard and defined by the RFCs, while 
others are enterprise specific. 


SNMP Agent Version and Architecture 


An EtherNet/IP device should provide an SNMP Agent that conforms to the requirements 
stated in this Appendix G. Implementation of such an Agent shall be indicated by the inclusion 
of the CIP SNMP Object (see Chapter 5). 


If an EtherNet/IP device implements the CIP SNMP Object, then: 


e An EtherNet/IP device shall implement only a single instance of the CIP SNMP Object. 
e An EtherNet/IP device shall provide an SNMP Agent. 
e An EtherNet/IP device may provide an SNMPvI1 Agent. 
= An EtherNet/IP device may provide an SNMPv3 Agent 
= An EtherNet/IP device may provide a bi-lingual SNMPv1+v3 agent. 
= If an EtherNet/IP device provides an SNMPv3 Agent then: 
— The SNMPv3 agent shall support snmpSecurityLevel ‘noAuthNoPriv’. 
— The SNMPv3 agent may support snmpSecurityLevel *‘AuthNoPriv’. 
— The SNMPvV3 agent may support snmpSecurityLevel ‘AuthPriv’. 
The architecture of a bi-lingual SNMP Agent is illustrated in [RFC 3411 sec 3.1.3.2]. This 
architecture view describes SNMP Agents whose Message Processing Subsystem includes one 
or more Message Processing Models. [RFC 3411 sec 3.1.1.3] 


SNMPyv1 Agent Requirements 
The SNMPv1 Agent shall conform to the following IETF RFCs: 


e RFC 1157, “A Simple Network Management Protocol (SNMP)”, May 1990 
e ~=RFC 1213, “Management Information Base for Network Management of TCP/IP- based 
Internets: MIB-II, Mar 1991 


SNMPv1 Agent PDU Requirements 
The SNMPvI Agent shall support the SNMP PDUs according to Table G-2.1. 
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Table G-2.1 SNMPv1 PDUs 


Service PDU Name PDU Type Provision Requirement Level 
Class 
Read GetRequestPdu OxAO Receive shall 
Read GetNextRequestPdu OxAI Receive shall 
Write SetRequestPdu OxA3 Receive shall 
Response ResponsePdu OxA2 Generate shall 
Notification | TrapV1Pdu OxA4 Generate Conditional ' 


Table Footnotes 


1 


If the SNMPv1 Agent provides SNMP Notifications then the SNMPv1 Agent shall support TrapV 1 Pdus 


SNMPv1 Agent Notification Requirements 


If the SNMPv1 Agent provides Notifications, then it shall follow the requirements specified in 
the following list. 


The SNMPv1 Agent shall follow the guidelines of IETF RFC 3413 cl 3.3 regarding the 
behavior of any Notification Originator Application that it provides. 

Notifications generated by the SNMPv1 Agent shall conform to the definitions for generic- 
traps as defined in [RFC 1157 sec 4.1.6] and/or enterpriseSpecific traps, as defined in 
[RFC 1157 sec 4.1.6]. 

The SNMPv1 Agent shall provide the sending of SNMP Trap Pdus using unicast 
communications. 


The sending of SNMP Trap Pdus by the SNMPv1 Agent using multicast communications 
is NOT recommended. 


SNMPv1 Agent Security and Administration Requirements 


The SNMPv1 Agent shall provide the capability of user configuration of the value of the 
‘community’ field of the SNMP Message. 


Although guidelines for the definition of administration relationships are provided in [RFC 
1157 sec 3.2.5], there are no administration relationships defined by this specification. 


SNMPv3 Agent Requirements 
The SNMPv3 Agent shall conform to the following IETF RFCs: 


RFC 1213 , “Management Information Base for Network Management of TCP/IP- based 
Internets: MIB-II, Mar 1991 


RFC 2011, “SNMPv2 Management Information Base for the Internet Protocol using 
SMIv2, Nov 1996 

RFC 2012, “SNMPv2 Management Information Base for the Transmission Control 
Protocol using SMIv2”, Nov 1996 

RFC 2013 , “SNMPv2 Management Information Base for the User Datagram Protocol 
using SMIv2, Nov 1996 

RFC 2578, “Structure of Management Information Version 2 (SMIv2)”, Apr 1999 
RFC 2579, “Textual Conventions for SMIv2”, Apr 1999 

RFC 2580, “Conformance Statements for SMIv2”, Apr 1999 

RFC 2863, “The Interfaces Group MIB”, Jun 2000 

RFC 3410, “Introduction and Applicability Statements for Internet Standard Management 
Framework”, Dec 2002 
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e RFC 3411, “An Architecture for Describing Simple Network Management Protocol 
(SNMP) Management Frameworks”, Dec 2002 

e RFC 3412, “Message Processing and Dispatching for the Simple Network Management 
Protocol (SNMP), Dec 2002 

e RFC 3413, “Simple Network Management Protocol (SNMP) Applications 

e RFC 3414, “User-based Security Model (USM) for version 3 of the Simple Network 
Management Protocol (SNMP), Dec 2002 

e RFC 3415, “View-based Access Control Model (VACM) for the Simple Network 
Management Protocol (SNMP), Dec 2002 

e RFC 3416, “Version 2 of the Protocol Operations for the Simple Network Management 
Protocol (SNMP), Dec 2002 

e RFC 3417, “Transport Mappings for the Simple Network Management Protocol (SNMP), 
Dec 2002 

e RFC 3584, “Coexistence between Version 1, Version 2, and Version 3 of the Internet- 
standard Network Management Framework”, Aug 2003 


e RFC 3635, “Definitions of Managed Objects for the Ethernet-like Interface Types”, Sep 
2003 


SNMPy3 Agent PDU Requirements 


The SNMPv3 Agent shall support the SNMP PDUs according to Table G-2.2. 
Table G-2.2 SNMPv3 PDUs 
Service PDU Name PDU Type Provision Requirement Level 
Class 
Read GetRequestPdu OxAO Receive shall 
Read GetNextRequestPdu OxAl Receive shall 
Read GetBulkRequestPdu OxAS Receive shall 
Write SetRequestPdu OxA3 Receive shall 
Response ResponsePdu OxA2 Generate shall 
Notification | TrapV2Pdu OxA7 Generate shall | 


Table Footnotes 


1 If the SNMPv1 Agent provides SNMP Notifications then the SNMPv1 Agent shall support 
TrapV1Pdus 


SNMPv3 Agent Notification Requirements 


If the SNMPv3 Agent provides Notifications, then it shall follow the requirements specified in 
the following list. 


e The SNMPv3 Agent shall follow the guidelines of IETF RFC 3413 cl 3.3 regarding the 
behavior of any Notification Originator Application that it provides. 
e Notifications generated by the SNMPv3 Agent shall 
= conform to the definitions for generic-traps as defined in [RFC 1157 sec 4.1.6] and/or 
enterpriseSpecific traps, as defined in [RFC 1157 sec 4.1.6] if it will send TrapV1Pdus. 
= conform to the definitions for generic-traps as defined in [RFC 3418 sec 2 and RFC 
2863 sec6] and/or enterpriseSpecific traps, as defined in [RFC 3418 sec 2] if it will 
send TrapV2Pdus. 
e The SNMPv3 Agent shall provide the sending of SNMP Trap Pdus using unicast 
communications. 
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G-2.4 


G-3 


G-3.1 


e The sending of SNMP Trap Pdus by the SNMPv3 Agent using multicast communications 
is NOT recommended. 


SNMPv3 Agent Security and Administration Requirements 


The SNMPv3 Agent may provide User-base Security. If the SNMPv3 Agent provides User- 
base Security, then the SNMPv3 Agent shall conform to RFC 3414. 


If the SNMPv3 Agent provides User-base Security, then the SNMPv3 Agent shall provide 
User-based Security with a ‘SecurityLevel’ of ‘noAuthNoPriv’ in conformance with RFC 3412 
sec 6.4. 


SNMPyv3 Agent View-based Access Control Requirements 


The SNMPv3 Agent may provide View-based Access Control. If the SNMPv3 Agent provides 
View-based Access Control, then the SNMPv3 Agent shall conform to the RFC 3514. 


SNMP Transport Mapping Requirements 


The SNMP Agent shall operate using UDP/IPv4 which is the preferred transport mapping. 
[RFC 3417 sec 3 


Base MIB View 


The Base MIB View provides a mapping of SNMP MIB elements to CIP Object Attributes. 
An EtherNet/IP device uses these mappings to process variable bindings in SNMP PDUs to 
access device data exposed through CIP Object Attributes. 


The Base MIB View also defines what other standard public MIB elements shall be provided 
by an EtherNet/IP device. 


Mapping of CIP Object Attributes to SNMP MIB Elements 


Using the CIP objects defined in the Generic Device Profile the following CIP Object Attribute 
mappings are defined. 


An EtherNet/IP device shall provide the SNMP MIB element to CIP Object Attribute mappings 
shown in Table G-3.1, Table G-3.2 and Table G-3.3 below. An EtherNet/IP device shall use 
these mappings to process variable bindings in SNMP PDUs to access device data exposed 
through CIP Object Attributes. 
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Table G-3.1 Mapping of Ethernet Link Object (ClassID = 0xF6) to SNMP MIB Elements 


CIP Object Instance Attributes SNMP MIB Elements 
Attr AttributeName CIP SMIv2 Element Name IETF SNMP 
Id DataType | DataType REC | Max_Access 
[RO or RW] 
1 Interface Speed UDINT Gauge32 ifSpeed 2863 RO 
3 Physical Address ARRAY of | OCTET ifPhysAddress 2863 RO 
6 USINTs STRING 
(6) 
4 Interface Counters | STRUCT of 
InOctets UDINT Counter32 | ifInOctets 2863 RO 
InUcastPackets UDINT Counter32 | iffnUcastPkts 2863 RO 
InNUcastPackets UDINT Counter32 | ifInNUcastPkts 2863 RO 
InDiscards UDINT Counter32 | ifInDiscards 2863 RO 
InErrors UDINT Counter32 | iff{nErrors 2863 RO 
TnUnknownProtos UDINT Counter32 | iffnUnknownProtos 2863 RO 
OutOctets UDINT Counter32 | ifOutOctets 2863 RO 
OutUcastPackets UDINT Counter32 | ifOutUcastPkts 2863 RO 
OutNUcastPackets UDINT Counter32 | ifOutNUcastPkts 2863 RO 
OutDiscards UDINT Counter32 | ifOutDiscards 2863 RO 
OutErrors UDINT Counter32 | ifOutErrors 2863 RO 
5 | Media Counters | STRUCT of 
Alignment Errors UDINT Counter32 | dot3StatsAlignmentErrors 3635 RO 
FCS Errors UDINT Counter32 | dot3StatsFCSErrors 3635 RO 
Single Collisions UDINT Counter32 | dot3StatsSingleCollisionFrames 3635 RO 
Multiple Collisions UDINT Counter32 | dot3StatsMultipleCollisionFrames 3635 RO 
SQE Test Errors UDINT Counter32 | dot3StatsSQETestErrors 3635 RO 
Deferred Transmissions UDINT Counter32 | dot3StatsDeferredTransmissions 3635 RO 
Late Collisions UDINT Counter32 | dot3StatsLateCollisions 3635 RO 
Excessive Collisions UDINT Counter32 | dot3StatsExcessiveCollisions 3635 RO 
MAC Transmit Errors UDINT Counter32 | dot3StatsInternalMacTransmitErrors 3635 RO 
Carrier Sense Errors UDINT Counter32_ | dot3StatsCarrierSenseErrors 3635 RO 
Frame Too Long UDINT Counter32_ | dot3StatsFrameTooLongs 3635 RO 
MAC Receive Errors UDINT Counter32 | dot3StatsInternalMacReceiveErrors 3635 RO 
6 | Interface Control STRUCT of 
Control Bits WORD n/a n/a n/a n/a 
Forced Interface Speed UINT n/a n/a n/a n/a 
Interface Type USINT INTEGER | ifT: ype” 2863 RO 
Interface State USINT INTEGER | IfOperStatus 2863 RO 
9 | Admin State USINT INTEGER | IfAdminStatus 2863 RW 
10 | Interface Label SHORT_ DisplayStr | IfDescr 2863 RO 
STRING ing Size 
(0... 255 
—~G-8 — 
Edition 1.18 


SINGLE SUBSCRIPTION ONLY; SUBSCRIPTION TERMS AND CONDITIONS OUTLINED ON PAGE (iii) 


Volume 2: EtherNet/IP Adaptation of CIP, Appendix G: SNMP Management Framework 


CIP Object Instance Attributes SNMP MIB Elements 
Attr AttributeName CIP SMIv2 Element Name IETF SNMP 
Id DataType | DataType REC | Max_Access 
[RO or RW] 
12 | HC Interface Counters | STRUCT of 
HCInOctets ULINT Counter64 | ifHCInOctets 2863 RO 
HCInUcastPkts ULINT Counter64 | ifHCInUcastPkts 2863 RO 
HCInMulticastPkts ULINT Counter64 | ifHCInMulticastPkts 2863 RO 
HCInBroadcastPkts ULINT Counter64 | ifHCInBroadcastPkts 2863 RO 
HCOutOctets ULINT Counter64 | ifHCOutOctets 2863 RO 
HCOutUcastPkts ULINT Counter64 | ifHCOutUcastPkts 2863 RO 
HCOutMulticastPkts ULINT Counter64 | ifHCOutMulticastPks 2863 RO 
HCOutBroadcastPkts ULINT Counter64 | ifHCOutBroadcastPkts 2863 RO 
13 | HC Media Counters | STRUCT of 

HCStatsAlignmentErrors | ULINT Counter64 | dot3HCStatsAlignmentErrors 3635 RO 
HCStatsFCSErrors ULINT Counter64 | dot3HCStatsFCSErrors 3635 RO 
HCStatsInternalMacTran | ULINT Counter64 | dot3HCStatsInternalMacTransmitErrors 3635 RO 
smitErrors 

HCStatsFrameTooLongs | ULINT Counter64 | dot3HCStatsFrameTooLongs 3635 RO 
HCStatsInternalMacRece | ULINT Counter64 | dot3HCStatsInternalMacReceiveErrors 3635 RO 
iveErrors 

HCStatsSymbolErrors ULINT Counter64 | dot3HCStatsSymbolErrors 3635 RO 


Table Footnotes 


1. 


The counters can be cleared from the CIP interface but not from the SNMP interface. Consequently the values may be different 
when read from each interface. 


2. ifType = other(1) mapped to Interface Type = 0, Unknown interface type. 
ifType = ethernetCsmacd(6) mapped to Interface Type = 2, Twisted-pair (e.g., 1OBase-T, 100Base-TX, 1000Base-T, etc.) 
ifType = fddi(15) mapped to Interface Type = 3, Optical fiber (e.g., 100Base-FX) 
Table G-3.2. Mapping of TCP/IP Interface Object (ClassID = 0xF5) to SNMP MIB Elements 
CIP Object Instance Attributes SNMP MIB Elements 
Attr AttributeName cIPp MIB DataType Element Name IETF RFC SNMP 
Id DataType Max_Access 
5 Interface STRUCT 
Configuration of 
IP Address UDINT IpAddress ipAdEntAddr 2011 RO 
Network Mask UDINT IpAddress ipAdEntNetMask 2011 RO 
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Table G-3.3 Mapping of Identity Object (ClassID = 0x01) to SNMP MIB Elements 


CIP Object Instance Attributes SNMP MIB Elements 
Attr AttributeName cIP MIB DataType Element Name IETF RFC SNMP 
Id DataType Max_Access 
15 | Assigned_Name STRINGI DisplayString Size | sysName 1213 RW 
(0... 255) 
16 | Assigned_Description | STRINGI DisplayString Size | sysDescr 1213 RO 
(0... 255) 
17. | Geographic_Location STRINGI DisplayString Size | sysLocation 1213 RW 
(0... 255) 
G-3.2 SNMP MIB Modules 


Table G-3.4 identifies MIB Modules and their corresponding IETF RFCs for which mappings 
to CIP Object Attributes are identified in section G-3.1, 


Table G-3.4 MIB Modules and 


Corresponding IETF RFCs 


MIB Module IETF RFC(s) Requirement Level 
System Group 1213 shall 
IP Group 2011 shall 
Interfaces Group 2863 shall 
Ethernet Like Statistics Group 3635 shall 


Table G-3.5 identifies MIB Modules and their corresponding IETF RFCs that provide SNMP 


access to elements of the core TCP/IP stack. 


Table G-3.5 MIB Modules and Corresponding IETF RFCs 


MIB Module IETF RFC(s) Requirement Level 
ICMP Group 2011 should 
TCP Group 2012 should 
UDP Group 2013 should 
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G-3.3 Mapping of CIP Object Attributes to PRP SNMP MIB Elements 
The following tables are for informational purposes only. Using appropriate CIP objects, the 
following CIP Object Attribute mappings to pertinent PRP SNMP MIB Elements are defined. 
Table G-3.6 Mapping of PRP Object (ClassID = 0x56) to PRP SNMP MIB Elements 
CIP Object Instance Attributes SNMP MIB Elements 
SNMP 
fa Attribute Name CIP DataType Ae a Element Name Reference Max_Access 
ue [RO or RW] 
1 PRP Enable BOOL 
2 Node Type UINT INTEGER IreNodeType TEC 62439-3 RW 
3 Node Name SHORT_STRING DisplayString | IreNodeName TEC 62439-3 RW 
4 Version Name SHORT_STRING OCTET IreVersionName TEC 62439-3 RO 
STRING 
5 PRP MAC Address. | ETH_MAC_ADDR | MacAddress | IreMacAddress TEC 62439-3 RW 
6 Duplicate Discard UINT INTEGER IreDuplicateDiscard | IEC 62439-3 RW 
Transparent UINT INTEGER IreTransparentRece | IEC 62439-3 RW 
Reception ption 
8 PRP Interface STRUCT of 
Counters 
Transmit Count A UDINT Counter32 IreCntTxA TEC 62439-3 RO 
Transmit Count B UDINT Counter32 IreCntTxB TEC 62439-3 RO 
Transmit Count C UDINT Counter32 IreCntTxC TEC 62439-3 RO 
Receive Count A UDINT Counter32 IreCntRxA TEC 62439-3 RO 
Receive Count B UDINT Counter32 IreCntRxB TEC 62439-3 RO 
Receive Count C UDINT Counter32 IreCntRxC TEC 62439-3 RO 
Wrong LAN A UDINT Counter32 IreCntErrWrongLan | IEC 62439-3 RO 
Count A 
Wrong LAN B UDINT Counter32 IreCntErrWrongLan | IEC 62439-3 RO 
Count B 
9 PRP Duplicate STRUCT of 
Detection Counters 
Entries Unique UDINT Counter32 IreCntUniqueA TEC 62439-3 RO 
Count A 
Entries Unique UDINT Counter32 IreCntUniqueB TEC 62439-3 RO 
Count B 
Entries Duplicate UDINT Counter32 IreCntDuplicateA TEC 62439-3 RO 
Count A 
Entries Duplicate UDINT Counter32 reCntDuplicateB TEC 62439-3 RO 
Count B 
Entries Multiple UDINT Counter32 IreCntMultiA TEC 62439-3 RO 
Count A 
Entries Multiple UDINT Counter32 IreCntMultiB. TEC 62439-3 RO 
Count B 
-G-1l- 
Edition 1.18 


SINGLE SUBSCRIPTION ONLY; SUBSCRIPTION TERMS AND CONDITIONS OUTLINED ON PAGE (iii) 


Volume 2: EtherNet/IP Adaptation of CIP, Appendix G: SNMP Management Framework 


Table G-3.7 Mapping of Pertinent Ethernet Link Object (ClassID = 0xF6) attributes to PRP 
SNMP MIB Elements for PRP LAN A 


CIP Object Instance Attributes SNMP MIB Elements 
SNMP 
ae Attribute Name CIP DataType ae ey Element Name Reference Max_Access 
ahs [RO or RW] 
2 Interface Flags DWORD INTEGER IreLinkStatusA. TEC 62439-3 RO 
4 Interface Counters STRUCT of 
In Errors UDINT Counter32 IreCntErrorA, TEC 62439-3 RO 
9 Admin State USINT INTEGER IrePortAdminState | TEC 62439-3 RW 
A 
Table G-3.8 Mapping of Pertinent Ethernet Link Object (ClassID = 0xF6) attributes to PRP 
SNMP MIB Elements for PRP LAN B 
CIP Object Instance Attributes SNMP MIB Elements 
Attr Attribute Name CIP DataType SMIv2 Element Name Reference SNMP 
Id DataType Max_Access. 
[RO or RW] 
Interface Flags DWORD INTEGER IreLinkStatusB TEC 62439-3 RO 
Interface Counters STRUCT of 
Tn Errors, UDINT Counter32 IreCntErrorB TEC 62439-3 RO 
9 Admin State USINT INTEGER IrePortAdminState | IEC 62439-3 RW 
B 
Table G-3.9 Mapping of Pertinent Ethernet Link Object (ClassID = 0xF6) attributes to PRP 
SNMP MIB Elements for PRP Redundancy Box Port C 
CIP Object Instance Attributes SNMP MIB Elements 
Attr Attribute Name CIP DataType SMIv2 Element Name Reference SNMP 
Id DataType Max_Access. 
[RO or RW] 
Interface Flags DWORD INTEGER IreLinkStatusC TEC 62439-3 RO 
Interface Counters STRUCT of 
In Errors UDINT Counter32 IreCntErrorC TEC 62439-3 RO 
9 | Admin State USINT INTEGER IrePortAdminState | IEC 62439-3 RW 
c 
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